[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LSU.2.11.1610191131250.2258@t29.fhfr.qr>
Date: Wed, 19 Oct 2016 11:33:41 +0200 (CEST)
From: Richard Biener <rguenther@...e.de>
To: Peter Zijlstra <peterz@...radead.org>
cc: "Luis R. Rodriguez" <mcgrof@...nel.org>,
Vegard Nossum <vegard.nossum@...cle.com>,
Jiri Slaby <jslaby@...e.cz>, linux-kernel@...r.kernel.org,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
stable@...r.kernel.org, Ming Lei <ming.lei@...onical.com>,
Steven Rostedt <srostedt@...hat.com>,
"H. Peter Anvin" <hpa@...or.com>,
Josh Poimboeuf <jpoimboe@...hat.com>,
Cesar Eduardo Barros <cesarb@...arb.eti.br>,
Michael Matz <matz@...e.de>,
David Miller <davem@...emloft.net>,
Guenter Roeck <linux@...ck-us.net>,
Fengguang Wu <fengguang.wu@...el.com>,
Borislav Petkov <bp@...en8.de>,
Boris Ostrovsky <boris.ostrovsky@...cle.com>,
Juergen Gross <jgross@...e.com>,
Kees Cook <keescook@...omium.org>,
Arnaldo Carvalho de Melo <acme@...nel.org>,
Ingo Molnar <mingo@...nel.org>,
Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH 01/12] extarray: define helpers for arrays defined in
linker scripts
On Wed, 19 Oct 2016, Peter Zijlstra wrote:
> On Wed, Oct 19, 2016 at 10:18:43AM +0200, Richard Biener wrote:
>
> > The commit implements a long-standing failure to optimize trivial pointer
> > comparisons that arise for example from libstdc++. PR65686 contains
> > a simple C example:
> >
> > mytype f(struct S *e)
> > {
> > mytype x;
> > if(&x != e->pu)
> > __builtin_memcpy(&x, e->pu, sizeof(unsigned));
> > return x;
> > }
> >
> > where GCC before the commit could not optimize the &x != e->pu test
> > as trivial false.
>
> Which is fine; x is stack based and could not possibly have been handed
> as the argument to this same function.
Sure, it was just one example.
> This is also an entirely different class of optimizations than the whole
> pointer arithmetic is only valid inside an object thing.
Yes, it is not related to that. I've opened
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78035 to track an
inconsistency in that new optimization.
> The kernel very much relies on unbounded pointer arithmetic, including
> overflow. Sure, C language says its UB, but we know our memory layout,
> and it would be very helpful if we could define it.
It's well-defined and correctly handled if you do the arithmetic
in uintptr_t. No need for knobs.
> Can't we get a knob extending -fno-strict-aliasing to define pointer
> arithmetic outside of objects and overflow? I mean, we already use that,
> we also use -fno-strict-overflow and a whole bunch of others.
>
> At the very least, it would be nice to get a -W flag for when this alias
> analysis stuff kills something so we can at least know when GCC goes and
> defeats us.
What kind of warning do you envision?
"warning: optimized address comparison to always true/false"
? That would trigger all over the place.
Richard.
Powered by blists - more mailing lists