lra incorrectly reloading scratch for a memory barrier?

Mike Stump mikestump@comcast.net
Fri Jan 30 22:14:00 GMT 2015


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?


More information about the Gcc-patches mailing list