Am 24. April 2019 20:43:03 MESZ schrieb Jeff Law <l...@redhat.com>: >On 4/24/19 4:24 AM, Richard Biener wrote: >> On Fri, Apr 19, 2019 at 11:09 AM Jens Gustedt <jens.gust...@inria.fr> >wrote: >>> >>> Hello Jakub, >>> >>> On Fri, 19 Apr 2019 10:49:08 +0200 Jakub Jelinek <ja...@redhat.com> >>> wrote: >>> >>>> On Fri, Apr 19, 2019 at 10:19:28AM +0200, Jens Gustedt wrote: >>>>>> OTOH GCC transforms >>>>>> (uintptr_t)&a != (uintptr_t)(&b+1) >>>>>> into &a != &b + 1 (for equality compares) and then >>>>>> doesn't follow this C rule anyways. >>>>> >>>>> Actually our proposal we are discussing here goes exactly the >other >>>>> way around. It basically reduces >>>>> >>>>> &a != &b + 1 >>>>> >>>>> to >>>>> >>>>> (uintptr_t)&a != (uintptr_t)(&b+1) >>>>> >>>>> with only an exception for null pointers, but which probably don't >>>>> matter for a platform where null pointers are just all bits 0. >>>> >>>> That penalizes quite a few optimizations though. >>>> If you have >>>> ptr != ptr2 >>>> and points-to analysis finds a set of variables ptr as well as ptr2 >>>> points to and the sets would be disjoint, it would be nice to be >able >>>> to optimize that comparison away >>> >>> yes >>> >>>> (gcc does); >>> >>> great >>> >>>> similarly, if one of the >>>> pointers is &object or &object + sizeof (object). >>> >>> Here I don't follow. Why would one waste brain and ressources to >>> optimize code that does such tricks? >>> >>>> By requiring what you request above, it can be pretty much never >>>> optimized, unless the points-to analysis is able to also record if >>>> the pointer points to the start, middle or end of object and only >if >>>> it is known to be in the middle it can safely optimize, for start >or >>>> end it would need to prove the other pointer is to end or start and >>>> only non-zero sized objects are involved. >>> >>> I have the impression that you just propose an inversion of the >>> roles. What you require is the user to keep track of this kind of >>> information, and to know when they do (or should not) compare a >>> one-passed pointer to something with a different provenance. >>> >>> I just don't feel that it is adequate to impose such a detailed >>> knowledge on users, which is basically about a marginal use >>> case. One-off pointers don't occur "naturally" in many places, >> >> They occur in the single important place - loop IV tests in >> C++ style iterator != end where end is a "pointer" to one after >> the last valid iterator value. >I don't think this is limited to C++.
Sure, but still this is "usually" compared to a pointer into the array. If it is not, something fundamentally went wrong. If a compiler detects this, great, but that is a qoi issue. I would not expect a compiler to optimize much in such a situation, the first objective would be to point to the logical error. So I really would like to hear about other aspects of our proposal. It would be good if we could agree on the fundamentals, first, and then sort out marginal cases later. Jens -- Jens Gustedt - INRIA & ICube, Strasbourg, France
