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
