On Thu, 27 Feb 2020, Jakub Jelinek wrote: > On Thu, Feb 27, 2020 at 10:30:21AM +0100, Richard Biener wrote: > > Obviously I don't like the repetitive boiler-plate after > > the ranges_known_overlap_p checks so I wonder if we can at least > > factor those into a VN-local ranges_known_overlap_for_pd_p predicate. > > I can do that.
OK. > > Wouldn't it be possible to simply constrain both sizes to half > > of the address space? Then the ranges_known_overlap_p should > > guarantee that we can represent the difference between the > > offsets in a signed HWI? > > Well, it is already 1/8th of address space for 64-bit VA, so that would > be 1/16th then. Doing it in ranges_known_overlap_p might be too > restrictive, other places might handle those fine. > > Perhaps we should also rule out the case when pd.offset would be minimum, > because we e.g. use -pd.offset, or when it or pd.size would be maximum > (as we e.g. use r->size + 1). > > I'm also a little bit worried about possible overflows in > r->size = MAX (r->offset + r->size, newr.offset + newr.size) - > r->offset; > or > r->size = MAX (r->offset + r->size, > rafter->offset + rafter->size) - r->offset; > While in ranges_known_overlap_for_pd_p we'd ensure that *->offset + *->size > doesn't overflow, the subtraction still could. Hmm, maybe. So basically memset (p - large, 0, even-larger); [p - large, p + 1] memset (p, 0, large); [p, p + large] and a read [p, p + 1] then we'll have very small (negative) r->offset and rafter->offset + rafter->size will be very large and we'll get up to SHWI_MAX - SWHI_MIN here. Now the thing here would be to note that the [p, p + 1] lookup is constraining what we need to track and we could prune partial-defs easily (the uniform ones). Of course that's extra code with possible sources of bugs. Or we'll bite the bullet and use widest_int (or offset_int?) for pd_range/pd_data offset/size pairs. Richard.
