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
--
H.J.
