On Tue, Jan 5, 2016 at 8:30 PM, Uros Bizjak <ubiz...@gmail.com> wrote:
> On Tue, Jan 5, 2016 at 8:20 PM, H.J. Lu <hjl.to...@gmail.com> wrote:
>> On Tue, Jan 5, 2016 at 11:14 AM, Uros Bizjak <ubiz...@gmail.com> wrote:
>>> 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.
>>
>> My patches only change SSE patterns without ssememalign
>> attribute, which defaults to
>>
>> (define_attr "ssememalign" "" (const_int 0))
>
> The patch is OK for mainline.
>
> (subst.md changes can IMO be considered obvious.)
This change (r232087 or r232088) is responsible for a drop
of 482.sphinx3 on AMD Fam15 (bulldozer) from score 33 to 18.
See http://gcc.opensuse.org/SPEC/CFP/sb-megrez-head-64-2006/recent.html
The tester on a Haswell machine doesn't seem to be affected.
Richard.
> Thanks,
> Uros.
