On 19/04/2019, Jens Gustedt <jens.gust...@inria.fr> wrote: > Hello Peter, > > On Fri, 19 Apr 2019 10:11:43 +0100 Peter Sewell > <peter.sew...@cl.cam.ac.uk> wrote: > >> On 19/04/2019, Jakub Jelinek <ja...@redhat.com> 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?
I was conflating two things, sorry. I meant an adaption of PNVI-ae-udi that would let implementations turn off the udi part if they wish. Then for those, casting a one-past pointer into integer and back would give an empty-provenance pointer that couldn't be used for accesses, which helps with the p[-1] examples that Richard was thinking of. As we think this roundtrip casting of a one-past pointer might be an exotic corner case, this might be reasonable. This: >> > 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) seems to be an argument to keep pointer == nondeterministically provenance-sensitive or not, though whether it outweighs the simplicity gain of making == just examine the address isn't clear to me. My inclination would still be to the latter. best, Peter > 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 :: >
