On Tue, Jan 5, 2016 at 7:58 PM, H.J. Lu <hjl.to...@gmail.com> wrote: > On Tue, Jan 5, 2016 at 4:32 AM, H.J. Lu <hjl.to...@gmail.com> wrote: >> On Tue, Jan 5, 2016 at 12:11 AM, Jakub Jelinek <ja...@redhat.com> wrote: >>> On Mon, Jan 04, 2016 at 03:25:48PM -0800, H.J. Lu wrote: >>>> LRA is fine. I should use >>>> >>>> (define_memory_constraint "Bm" >>>> "@internal Vector memory operand." >>>> (match_operand 0 "vector_memory_operand")) >>>> >>>> instead of >>>> >>>> (define_constraint "Bm" >>>> "@internal Vector memory operand." >>>> (match_operand 0 "vector_memory_operand")) >>> >>> I don't think so. At least the documentation says that >>> define_memory_constraint is for MEM constraints where if they are not >>> satisfied they can be made to satisfy by forcing the address into a >>> register. But that is not the case here, if a MEM is misaligned, no >>> equivalent changes to the XEXP (mem, 0) will make it aligned. >>> >> >> You are right and *mov<mode>_internal must use the 'm' constraint >> so that LRA won't keep generating the same reload for >> >> (insn 353 322 323 8 (set (reg:V4SF 192) >> (reg:V4SF 201 [192])) 1226 {*movv4sf_internal} >> (nil)) >> >> until >> >> x.i: In function \u2018foo\u2019: >> x.i:29:1: internal compiler error: Max. number of generated reload >> insns per insn is achieved (90) >> >> } >> ^ >> >> 0xc0d635 lra_constraints(bool) >> /export/gnu/import/git/sources/gcc/gcc/lra-constraints.c:4336 >> 0xbf9854 lra(_IO_FILE*) >> /export/gnu/import/git/sources/gcc/gcc/lra.c:2277 >> 0xba6489 do_reload >> /export/gnu/import/git/sources/gcc/gcc/ira.c:5385 >> 0xba683c execute >> /export/gnu/import/git/sources/gcc/gcc/ira.c:5556 >> >> > > Here are the updated patches. I didn't change SSE > *mov<mode>_internal. Tested on x86-64. OK for > trunk?
It is hard to determine the changed patterns - can you confirm that only patterns where ssememalign=0 are changed? Uros.