On 27/02/14 16:36, Yury Gribov wrote:
> Richard Biener wrote:
>>>> If this behavior is not intended, what would be the best way to fix
>>>> performance? I could teach GCC to not remove constant RTXs in
>>>> flush_hash_table() but this is probably very naive and won't cover some
>>>> corner-cases.
>>>
>>> That could be a good starting point though.
>>
>> Though with modifying "machine state" you can modify constants as
>> well, no?
>
> Valid point but this would mean relying on compiler to always load all
> constants from memory (instead of, say, generating them via movhi/movlo)
> for a piece of code which looks extremely unstable.
>
> What is the general attitude towards volatile asm? Are people interested
> in making it more defined/performant or should we just leave this can of
> worms as is? I can try to improve generated code but my patches will be
> doomed if there is no consensus on what volatile asm actually means...
>
> -Y
>
In embedded development, volatile asm statements are unavoidable at
times. In particular, "asm volatile ("" ::: "memory")" is the most
common memory barrier used, and it can turn up quite often. I would
definitely consider the regression you found to be an issue. And if it
is now the case that "asm volatile" causes a complete optimisation
barrier regardless of the clobber, this will definitely make code bigger
and slower in every case where you /don't/ "do really nasty things
behind the back of the compiler".
