This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Asm volatile causing performance regressions on ARM
- From: David Brown <david at westcontrol dot com>
- To: Yury Gribov <y dot gribov at samsung dot com>, Richard Biener <richard dot guenther at gmail dot com>, Eric Botcazou <ebotcazou at adacore dot com>
- Cc: GCC Development <gcc at gcc dot gnu dot org>, <hp at gcc dot gnu dot org>, Viacheslav Garbuzov <v dot garbuzov at samsung dot com>, Yuri Gribov <tetra2005 at gmail dot com>
- Date: Thu, 27 Feb 2014 18:02:26 +0100
- Subject: Re: Asm volatile causing performance regressions on ARM
- Authentication-results: sourceware.org; auth=none
- References: <530F4D3A dot 4020800 at samsung dot com> <2054281 dot lbfa4qFJsN at polaris> <CAFiYyc20wRO=t98jh9iug2H=DctR2o7WVyLUu=84JaqhevqH3A at mail dot gmail dot com> <530F5B92 dot 6000807 at samsung dot com>
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".