[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ebfebd1bd01f43f099a4d08b4029013a@AcuMS.aculab.com>
Date: Mon, 20 Jun 2022 15:21:50 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Kent Overstreet' <kent.overstreet@...il.com>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-mm@...ck.org" <linux-mm@...ck.org>,
"pmladek@...e.com" <pmladek@...e.com>,
"rostedt@...dmis.org" <rostedt@...dmis.org>,
"enozhatsky@...omium.org" <enozhatsky@...omium.org>,
"linux@...musvillemoes.dk" <linux@...musvillemoes.dk>,
"willy@...radead.org" <willy@...radead.org>
Subject: RE: [PATCH v4 00/34] Printbufs - new data structure for building
strings
From: Kent Overstreet
> Sent: 20 June 2022 16:07
> On Mon, Jun 20, 2022 at 04:19:31AM +0000, David Laight wrote:
> > From: Kent Overstreet
> > > Rasmus pointed out that -fno-strict-aliasing is going to cause gcc to generate
> > > nasty code, and indeed it unfortunately does but according to worst case
> > > scenario microbenchmarks it's not a problem for actual performance.
> >
> > Just copy some of the structure members to local variables
> > and, if necessary, write them back at the end.
>
> You must not have read any of the code - half the point of this patch series is
> implementing proper helpers for printing chars, strings of bytes, etc. and that
> doesn't work if we're not using actual types.
I'm talking about things like:
out->buf[out->pos] = c;
(or whatever the field names are.)
Even without strict aliasing the compiler has to reread
'buf' and 'pos' every iteration.
Of course, you might find the compiler decides to 'optimise'
the loop to memcpy() or memset().
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
Powered by blists - more mailing lists