On Sat, 1 Jul 2017, Marc Glisse wrote: > On Thu, 22 Jun 2017, Richard Biener wrote: > > > On Thu, 22 Jun 2017, Marc Glisse wrote: > > > > > On Thu, 22 Jun 2017, Richard Biener wrote: > > > > > > > > If we consider pointers as unsigned, with a subtraction that has a > > > > > signed > > > > > result with the constraint that overflow is undefined, we cannot model > > > > > that > > > > > optimally with just the usual signed/unsigned operations, so I am in > > > > > favor > > > > > of > > > > > POINTER_DIFF, at least in the long run (together with having a signed > > > > > second > > > > > argument for POINTER_PLUS, etc). For 64-bit platforms it might have > > > > > been > > > > > easier to declare that the upper half (3/4 ?) of the address space > > > > > doesn't > > > > > exist... > > > > > > > > I repeatedly thought of POINTER_DIFF_EXPR but adding such a basic tree > > > > code is quite a big job. > > > > > > Yes :-( > > > It is probably not realistic to introduce it just to avoid a couple > > > regressions while fixing a bug. > > > > > > > So we'd have POINTER_DIFF_EXPR take two pointer typed args and produce > > > > ptrdiff_t. What's the advantage of having this? > > > > > > It represents q-p with one statement instead of 3 (long)q-(long)p or 4 > > > (long)((ulong)q-(ulong)p). It allows us to stay in the pointer world, so > > > (q-p)>0 is equivalent to p<q, not just (long)p<(long)q. It properly models > > > what (undefined) overflow means for pointers. > > > > > > Of course it is hard to know in advance if that's significant or > > > negligible, maybe size_t finds its way in too many places anyway. > > > > As with all those experiments ... > > > > Well, if I would sell this as a consultant to somebody I'd estimate > > 3 man months for this work which realistically means you have to > > start now otherwise you won't make it this stage 1. > > I wrote a quick prototype to see what the fallout would look like. > Surprisingly, it actually passes bootstrap+testsuite on ppc64el with all > languages with no regression. Sure, it is probably not a complete > migration, there are likely a few places still converting to ptrdiff_t > to perform a regular subtraction, but this seems to indicate that the > work isn't as bad as using a signed type in pointer_plus_expr for > instance.
The fold_binary_loc hunk looks dangerous (it'll generate MINUS_EXPR from POINTER_MINUS_EXPR in some cases I guess). The tree code needs documenting in tree.def and generic.texi. Otherwise ok(*). Thanks, Richard. (*) ok, just kidding -- or maybe not
