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. -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html