Re: C provenance semantics proposal
Hello, On Thu, 18 Apr 2019 14:42:22 +0200 Richard Biener wrote: > On Thu, Apr 18, 2019 at 2:20 PM Uecker, Martin > wrote: > > 1.) Compilers do not use conditional equivalences for > > optimizations of pointers (or only when additional > > conditions apply which make it safe) > > > > 2.) We make pointer comparison between a pointer > > and a one-after pointer of a different object > > undefined behaviour. > > Yes please! No please don't, not UB. If any of this, make the result unspecified but not UB, please. > 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. Jens -- :: INRIA Nancy Grand Est ::: Camus ::: ICube/ICPS ::: :: ::: office Strasbourg : +33 368854536 :: :: :: gsm France : +33 651400183 :: :: ::: gsm international : +49 15737185122 :: :: http://icube-icps.unistra.fr/index.php/Jens_Gustedt :: pgpVQ3zYW3gyA.pgp Description: Digitale Signatur von OpenPGP
Re: C provenance semantics proposal
Hello Jakub, On Fri, 19 Apr 2019 10:49:08 +0200 Jakub Jelinek 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, I'd guess. Using them for anything else than to test bounds for array traversal is insane, and there "usually" the test is with `<`, anyhow, which has different rules. Jens -- :: INRIA Nancy Grand Est ::: Camus ::: ICube/ICPS ::: :: ::: office Strasbourg : +33 368854536 :: :: :: gsm France : +33 651400183 :: :: ::: gsm international : +49 15737185122 :: :: http://icube-icps.unistra.fr/index.php/Jens_Gustedt :: pgpty1EWE_UGa.pgp Description: Digitale Signatur von OpenPGP
Re: C provenance semantics proposal
Hello Peter, On Fri, 19 Apr 2019 10:11:43 +0100 Peter Sewell wrote: > On 19/04/2019, Jakub Jelinek wrote: > > On Fri, Apr 19, 2019 at 10:19:28AM +0200, Jens Gustedt wrote: > [...] > > 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 (gcc does); similarly, if one > > of the pointers is &object or &object + sizeof (object). > > 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. > > A possible compromise position might be to make it > implementation-defined whether round-trip casts of a one-past pointer > into integer and back preserve provenance. I don't know whether > that corner case crops up in real code... Wouldn't that impose to keep track of some provenance information in integers? Jens -- :: INRIA Nancy Grand Est ::: Camus ::: ICube/ICPS ::: :: ::: office Strasbourg : +33 368854536 :: :: :: gsm France : +33 651400183 :: :: ::: gsm international : +49 15737185122 :: :: http://icube-icps.unistra.fr/index.php/Jens_Gustedt :: pgpchhr4r7S_a.pgp Description: Digitale Signatur von OpenPGP
Re: C provenance semantics proposal
Hello Jakub, On Fri, 19 Apr 2019 11:34:33 +0200 Jakub Jelinek wrote: > On Fri, Apr 19, 2019 at 11:09:27AM +0200, Jens Gustedt wrote: > > > 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? > > What tricks? &object + sizeof (object) > A normal pointer comparison either of two pointers > or a pointer and address of something is something that happens in > real-world code all the time, and in many cases it is essential > that optimizing compilers attempt to optimize such tests as much as > possible. Yes, but not if one of the addresses is a one-passed pointer, this is a marginal use case. > In the http://gcc.gnu.org/PR88775 (yes, it is C++, not C, but I don't > see significant differences there), Hm, probably my C++ is a bit rusty, but I see huge differences here. What understand is that you have difficulties for some C++ code that uses `operator=` overloading (instead of initialization) to optimize that assignment. I see a lot of difficulties here, of which some are common for C and C++ (the lack of proper treatement of string literals as constants, for example) to purely C++ difficulties, e.g not being able to model `restrict` pointer arguments, and to deal with possible (or impossible) aliasing between a just created object and a string literal. So, I see a whole chain of reasoning breaking down with that code, but nothing that convinces me that `operator==` for pointer types is the culprit. The wrong is probably already done when it comes to it. Jens -- :: INRIA Nancy Grand Est ::: Camus ::: ICube/ICPS ::: :: ::: office Strasbourg : +33 368854536 :: :: :: gsm France : +33 651400183 :: :: ::: gsm international : +49 15737185122 :: :: http://icube-icps.unistra.fr/index.php/Jens_Gustedt :: pgptFS25gjDsj.pgp Description: Digitale Signatur von OpenPGP
Re: C provenance semantics proposal
Am 24. April 2019 20:43:03 MESZ schrieb Jeff Law : >On 4/24/19 4:24 AM, Richard Biener wrote: >> On Fri, Apr 19, 2019 at 11:09 AM Jens Gustedt >wrote: >>> >>> Hello Jakub, >>> >>> On Fri, 19 Apr 2019 10:49:08 +0200 Jakub Jelinek >>> 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
