lra incorrectly reloading scratch for a memory barrier?

[Richard Biener]

On January 30, 2015 9:12:12 PM CET, Mike Stump <mikestump@comcast.net> 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?

There would be the subtle difference that the set keeps all previous memory live while the clobber is only a barrier for memory instruction movement.

Richard.