This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: volatile access optimization (C++ / x86_64)
- From: Andrew Haley <aph at redhat dot com>
- To: Matt Godbolt <matt at godbolt dot org>
- Cc: GCC Development <gcc at gcc dot gnu dot org>
- Date: Sat, 27 Dec 2014 18:40:30 +0000
- Subject: Re: volatile access optimization (C++ / x86_64)
- Authentication-results: sourceware.org; auth=none
- References: <CAFWXXN3quEdSnaoWuPcQn2k-F99Yaw+6=NqgFgcu9ABpv5ZD3Q at mail dot gmail dot com> <549DE09B dot 8060502 at redhat dot com> <CAFWXXN0V9yvNTpcz54DCK237KPURQs1XkaHcQZK5Eoj_VCj0OA at mail dot gmail dot com> <549DED1B dot 3070006 at redhat dot com> <CAFWXXN13eKJVP0z6V6DEVwoxZtqo4Z0nnQA2YFd9+4UWJxrnVg at mail dot gmail dot com> <549EF314 dot 5060305 at redhat dot com> <CAFWXXN03T7dT8FGNgnaZf9Kq+hZu4e6pZqEWRb3BQsSjrzRCLw at mail dot gmail dot com>
On 27/12/14 18:04, Matt Godbolt wrote:
> On Sat, Dec 27, 2014 at 11:57 AM, Andrew Haley <aph@redhat.com> wrote:
>> if you don't need an atomic access, why do you care that it uses a
>> read-modify-write instruction instead of three instructions? Is it
>> faster? Have you measured it? Is it so much faster that it's
>> critical for your application?
>
> Good point. No; I've yet to measure it but I will. I'll be honest: my
> instinct is that really it won't make a measurable difference. From a
> microarchitectural point of view it devolves to almost exactly the
> same set of micro-operations (barring the duplicate memory address
> calculation). It does encode to a longer instruction stream (15 bytes
> vs 7 bytes), so there's an argument it puts more pressure than needed
> on the i-cache. But honestly, it's more from an aesthetic point of
> view I prefer the increment.
Aha! I get it now.
I know that it's not really necessary to know a questioner's
motivation for a question like this: it makes no difference to the
answer. But you really had me mystified because I was assuming that
there had to be a practical reason for all this.
> Also, it's always nice to understand why particular optimisations
> aren't performed by the compiler from a correctness point of view! :)
Sure. Well, in this case you now know: it's a bug! But one that it's
fairly hard to care deeply about, although it might get fixed now.
Andrew.