On Tue, Apr 19, 2016 at 5:36 PM, H.J. Lu <hjl.to...@gmail.com> wrote: > On Tue, Apr 19, 2016 at 8:27 AM, Uros Bizjak <ubiz...@gmail.com> wrote: >> On Tue, Apr 19, 2016 at 5:18 PM, H.J. Lu <hjl.to...@gmail.com> wrote: >>> On Tue, Apr 19, 2016 at 8:08 AM, Uros Bizjak <ubiz...@gmail.com> wrote: >>>> On Tue, Apr 19, 2016 at 4:49 PM, H.J. Lu <hongjiu...@intel.com> wrote: >>>>> >>>>> From INSTRUCTION EXCEPTION SPECIFICATION section in Intel software >>>>> developer manual volume 2, only legacy SSE instructions with memory >>>>> operand not 16-byte aligned get General Protection fault. There is >>>>> no need to check 1, 2, 4, 8 byte alignments. Since x86 backend has >>>>> accurate constraints and predicates for 16-byte alignment, we can >>>>> remove ix86_legitimate_combined_insn. >>>>> >>>>> Tested on x86-64. OK for trunk? >>>> >>>> No. This function also handles cases where invalid hard register gets >>>> propagated into the insn during the combine pass, leading to spill >>>> failure later. >>>> >>> >>> ix86_legitimate_combined_insn was added to work around the >>> reload issue: >> >> Sorry, I'm not convinced. Please see [1]. >> >> You should remove only this part, together with now unused ssememalign >> attribute. >> >> - /* For pre-AVX disallow unaligned loads/stores where the >> - instructions don't support it. */ >> - if (!TARGET_AVX >> - && VECTOR_MODE_P (mode) >> - && misaligned_operand (op, mode)) >> - { >> - unsigned int min_align = get_attr_ssememalign (insn); >> - if (min_align == 0 >> - || MEM_ALIGN (op) < min_align) >> - return false; >> - } >> >>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46829 >>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46843 >> >>> LRA doesn't have those limitation. Removing >>> ix86_legitimate_combined_insn causes no regressions. >> >> [1] https://gcc.gnu.org/ml/gcc-patches/2012-08/msg01195.html >> >> Uros. > > Here is the updated patch. OK for trunk if there is no regression > on x86-64?
OK... BTW: I really hope that "INSTRUCTION EXCEPTION SPECIFICATION section" quoted above is correct - we will quickly find out. Thanks, Uros.