On 4/24/19 4:19 AM, Richard Biener wrote: > 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. But if we only suppress this optimization for pointers is it that terrible?
>>> >>> 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. But the calls aren't generating conditional equivalences. I must be missing something here. You're the expert in this space, so if you say it totally degrades PTA, then it's a non-starter. > > 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. Not a bad idea. I suspect the embedded folks would go bananas though. jeff
