lra incorrectly reloading scratch for a memory barrier?
Richard Henderson
rth@redhat.com
Sat Jan 31 00:20:00 GMT 2015
On 01/30/2015 12:40 PM, Richard Biener wrote:
> On January 30, 2015 9:18:57 PM CET, Richard Henderson <rth@redhat.com> wrote:
>> On 01/30/2015 12:12 PM, Mike Stump wrote:
>>> On Jan 30, 2015, at 9:52 AM, Jakub Jelinek <jakub@redhat.com> wrote:
>>>> On Fri, Jan 30, 2015 at 09:45:26AM -0800, Mike Stump wrote:
>>>>> I have a port that has:
>>>>>
>>>>> (insn 47 46 48 18 (parallel [
>>>>> (unspec_volatile:DI [
>>>>> (const_int 128 [0x80])
>>>>> (const_int 6 [0x6])
>>>>> ] UNSPECV_SPECIAL_OP)
>>>>> (set (mem/v:BLK (scratch:DI) [0 A8])
>>>>> (unspec:BLK [
>>>>> (mem/v:BLK (scratch:DI) [0 A8])
>>>>> ] UNSPEC_MEMORY_BARRIER))
>>>>
>>>> Why don't you just (clobber (mem/v:BLK (scratch:DI))) instead
>>>> of the second set in the parallel? The instruction is already
>>>> UNSPEC_VOLATILE, and to make the barrier effect clear a clobber
>> should be
>>>> sufficient.
>>>
>>> So, f087d65d84655bc2d5fdd4bcc6bf0fe337a39893 seems to have introduced
>> the current way that all the ports do this currently. So, I’d leave
>> this to Richard to answer.
>>>
>>> If (clobber (mem/v:BLK (scratch:DI))) works, certainly that seems
>> simpler than what people do now, but, then I’m left wondering, why
>> didn’t we do that from that start?
>>>
>>
>> Jakub, the current formation includes both a use and a set of all
>> memory. Your
>> clobber form would not imply a use.
>
> What do you need the use for? Prevent all DSE before the barrier for some weird reason?
I don't consider the clobber to be accurately representational of a barrier.
It may work by accident, because the scratch address prevents aliasing
disambiguation, but I don't think it's good form.
If we were talking about a register and not memory, the clobber would not
prevent movement of a store across the barrier. Do we really want different
rules for (mem (scratch)) than other rtl objects?
r~
More information about the Gcc-patches
mailing list