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