On Wed, Apr 24, 2019 at 8:41 PM Jeff Law <l...@redhat.com> wrote: > > 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?
I've at least seen a lot of cases with c = PHI <a, 0> for null pointer checks. It's just we're going to chase a lot of cases down even knowing RTL will fuck up later big times. > > > >>> > >>> 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. if (compare_a_and_b (a, b)) ... yes, they are not creating conditional equivalences that can be propagated out (w/o IPA info). But we compute points-to early, then inline (exposing the propagation opportunity), preserving the points-to result. > You're the expert in this space, so if you say > it totally degrades PTA, then it's a non-starter. Well, it's possible to fix all testcases that get thrown to us but what I have difficulties with is designing a way to follow the proposed standard. Btw, I've tried the trivial points-to patch for conditionals only and even that regressed points-to testcases. > > > > 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. Maybe, but those folks are also using -fno-strict-aliasing ... Anyhow, my issue is that I don't see a clean design that would follow the proposed standard wording (even our current desired implementation behavior btw!) and not degrade simple testcases :/ Richard. > jeff >
