On Thu, Apr 18, 2019 at 3:42 PM Jeff Law <l...@redhat.com> wrote: > > On 4/18/19 6:20 AM, Uecker, Martin wrote: > > Am Donnerstag, den 18.04.2019, 11:45 +0100 schrieb Peter Sewell: > >> On Thu, 18 Apr 2019 at 10:32, Richard Biener <richard.guent...@gmail.com> > >> wrote: > > > > > >> An equality test of two pointers, on the other hand, doesn't necessarily > >> mean that they are interchangeable. I don't see any good way to > >> avoid that in a provenance semantics, where a one-past > >> pointer might sometimes compare equal to a pointer to an > >> adjacent object but be illegal for accessing it. > > > > As I see it, there are essentially four options: > > > > 1.) Compilers do not use conditional equivalences for > > optimizations of pointers (or only when additional > > conditions apply which make it safe) > I know this will hit DOM and CSE. I wouldn't be surprised if it touches > VRP as well, maybe PTA. It seems simple enough though :-)
Also touches fundamental PHI-OPT transforms like if (a == b) ... # c = PHI <a, b> where we'd lose eliding such a conditional. IMHO that's bad and very undesirable. > > > > 2.) We make pointer comparison between a pointer > > and a one-after pointer of a different object > > undefined behaviour. > I generally like this as well, though I suspect it probably makes a lot > of currently well defined code undefined. > > > > > 3.) We make comparison have the side effect that > > afterwards any of the two pointers could have any > > of the two provenances. (with disambiguitation > > similar to what we have for casts). > This could have some interesting effects on PTA. Richi? I played with this and doing this in an incomplete way like just handling if (a == b) as two-way assignment during constraint building is possible. But that's not enough of course since every call is implicitely producing equivalences between everything [escaped] ... which makes points-to degrade to a point where it is useless. So I think we need a working scheme where points-to doesn't degrade from equivalencies being computed and the compiler being free to introduce equivalences as well as copy-propagate those. Honestly I can't come up with a working solution to this problem. > > > > > 4.) Compilers make sure that exposed objects never > > are allocated next to each other (as Jens proposed). > Ugh. Not sure how you enforce that. Consider that the compiler may > ultimately have no control over layout of data in static storage. Make everything 1 byte larger. > jeff
