This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: volatile access optimization (C++ / x86_64)

> On Dec 27, 2014, at 1:40 PM, Andrew Haley <> wrote:
> On 27/12/14 18:04, Matt Godbolt wrote:
>> On Sat, Dec 27, 2014 at 11:57 AM, Andrew Haley <> 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.

Letâs not forget -Os.  Most people optimize for speed, but optimization for size is needed at times and this is the sort of issue that affects it directly.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]