[PATCH] Reenable CSE of non-volatile inline asm (PR rtl-optimization/63637)

Richard Biener richard.guenther@gmail.com
Thu Jan 15 07:54:00 GMT 2015


On January 15, 2015 6:06:33 AM CET, Jeff Law <law@redhat.com> wrote:
>On 01/14/15 08:19, Segher Boessenkool wrote:
>
>> "
>> @findex clobber
>> @item (clobber @var{x})
>> Represents the storing or possible storing of an unpredictable,
>> undescribed value into @var{x}, which must be a @code{reg},
>> @code{scratch}, @code{parallel} or @code{mem} expression.
>>
>> [...]
>>
>> If @var{x} is @code{(mem:BLK (const_int 0))} or
>> @code{(mem:BLK (scratch))}, it means that all memory
>> locations must be presumed clobbered.
>> "
>>
>> Note it doesn't mention reading memory.
>The documentation is incomplete.  The right thing to do is fix the 
>documentation and treat  the "memory" tag appearing in the "clobber" 
>section as a read as well as a write.
>
>It's lame, but the historical decision by RMS to put that tag into the 
>clobbers section is what it is.  Don't get too hung up on it.  RMS just
>
>botched it.
>
>>
>> Now if we go back to my earlier quote:
>>
>> "
>> If your assembler instructions access memory in an unpredictable
>> fashion, add @samp{memory} to the list of clobbered registers.
>Note "access" not "write".
>
>
>  This
>> causes GCC to not keep memory values cached in registers across the
>> assembler instruction and not optimize stores or loads to that
>memory.
>> You also should add the @code{volatile} keyword if the memory
>> affected is not listed in the inputs or outputs of the @code{asm}, as
>> the @samp{memory} clobber does not count as a side-effect of the
>> @code{asm}.
>> "
>>
>> That last line means the compiler is free to delete a non-volatile
>> asm with a memory clobber if that asm is not needed for dataflow.  Or
>> that is how I read it; it is trying to indicate that if you want to
>> prevent the memory clobber from being deleted (together with the rest
>> of the asm), you need to make the asm volatile.
>>
>> So as far as I can see the compiler can CSE two identical
>non-volatile
>> asms with memory clobber just fine.  Older GCC (I tried 4.7.2) does
>do
>> this; current mainline doesn't.  I think it should.
>No, it should not CSE those two cases.  That's simply wrong and if an 
>older version did that optimization, that's a bug.

I think segher has a point here.  If the asm with memory clobber would store to random memory and the point would be to preserve that then the whole distinction with volatile doesn't make much sense (after all without volatile we happily DCE such asm if the regular outputs are not needed).

This doesn't mean 'memory' is a well-designed thing, of course. Just its effects are effectively limited to reads without volatile(?)

Richard.
>
>jeff




More information about the Gcc-patches mailing list