Re: [PATCH 01/12] extarray: define helpers for arrays defined in linker scripts

[Richard Biener]

On Wed, 19 Oct 2016, Peter Zijlstra wrote:

> On Wed, Oct 19, 2016 at 11:33:41AM +0200, Richard Biener wrote:
> > On Wed, 19 Oct 2016, Peter Zijlstra wrote:
> 
> > > 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.
> 
> So why not extend that to the pointers themselves and be done with it?
> 
> In any case, so you're saying our:
> 
> #define RELOC_HIDE(ptr, off)						\
> ({									\
> 	unsigned long __ptr;						\
> 	__asm__ ("" : "=r"(__ptr) : "0"(ptr));				\
> 	(typeof(ptr)) (__ptr + (off));					\
> })
> 
> could be written like:
> 
> #define RELOC_HIDE(ptr, off)			\
> ({						\
> 	uintptr_t __ptr = (ptr);		\
> 	(typeof(ptr)) (__ptr + (off));		\
> })
> 
> Without laundering it through inline asm?

I think so.

> Is there any advantage to doing so?

asms always introduce issues with optimization passes that do not
bother to handle it (and give up).  And then there is register
allocation - not sure how it is affected by the asm.

Generally I'd say if you can do it w/o asm then better..

Note that old GCC may have had bugs that made the uintptr_t variant
w/o the asm not work.

> But this still means we need to be aware of this and use these macros to
> launder our pointers.

Yes, if you base 'ptr' on the address of a declaration at least.
 
> Which gets us back to the issue that started this whole thread. We have
> code that now gets miscompiled, silently.
> 
> That is a bad situation. So we need to either avoid the miscompilation,
> or make it verbose.

GCC 7 is still not released and I think we should try not to break
things without a good reason.

> > > 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.
> 
> That is indeed what I was thinking of. And I have no idea how often that
> would trigger on the kernel.
> 
> I'm thinking that if this WARN isn't subject to false
> positives we could live with that. Its the false positives that render
> other warnings useless (too much noise on perfectly fine code etc..).
> 
> /me ponders..
> 
> So there might be a problem if this triggers in generic code due to
> conditions at its use site. There we would not want to, nor could, fix
> the generic code because in generic the thing would not be optimized. So
> maybe we'd need an annotation still.

For C++ these kind of warnings trigger whenever abstraction penalty
is removed.  Like the typical

 template <int i> foo () { if (i) { <code> } }

triggering for a hypothetical -Wdead-code for i == 0.  The kernel
is known for its "C" abstraction stuff and I can believe that
such -W flag would trigger for cases where abstraction is removed.

Richard.