Asm volatile causing performance regressions on ARM

Georg-Johann Lay gjl@gcc.gnu.org
Thu Feb 27 20:11:00 GMT 2014


Yury Gribov schrieb:
> 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...

It's definitely a can of worms, in my opinion.

asm volatile + memory clobber should be the last resort barrier, if you 
skip this out of the compiler or change its semantics (pinned by the 
current documentation) at will, it's not unlikely you break existing 
code in favour or saving some poor instructions.

For example, I had the case that a costly computation (division an a 
hardware that cannot divide) was moved into a section enclosed in asms 
which disabled / re-enabled interrupts.  This totally wrecked interrupt 
respond times on the machine.

Notice that such a division had no side effects from the C side or from 
the compiler's point of view, but execution time and interrupt respond 
times cannot be ignored by any software that does system programming.

Johann



More information about the Gcc mailing list