> alias.c encodes memory sizes as follows: > > size > 0: the exact size is known > size == 0: the size isn't known > size < 0: the exact size of the reference itself is known, > but the address has been aligned via AND. In this case > "-size" includes the size of the reference and the worst-case > number of bytes traversed by the AND. > > This patch wraps this up in a helper class and associated > functions. The new routines fix what seems to be a hole > in the old logic: if the size of a reference A was unknown, > offset_overlap_p would assume that it could conflict with any > other reference B, even if we could prove that B comes before A. > > The fallback CONSTANT_P (x) && CONSTANT_P (y) case looked incorrect. > Either "c" is trustworthy as a distance between the two constants, > in which case the alignment handling should work as well there as > elsewhere, or "c" isn't trustworthy, in which case offset_overlap_p > is unsafe. I think the latter's true; AFAICT we have no evidence > that "c" really is the distance between the two references, so using > it in the check doesn't make sense. > > At this point we've excluded cases for which: > > (a) the base addresses are the same > (b) x and y are SYMBOL_REFs, or SYMBOL_REF-based constants > wrapped in a CONST > (c) x and y are both constant integers > > No useful cases should be left. As things stood, we would > assume that: > > (mem:SI (const_int X)) > > could overlap: > > (mem:SI (symbol_ref Y)) > > but not: > > (mem:SI (const (plus (symbol_ref Y) (const_int 4))))
Frankly this seems to be an example of counter-productive C++ization: the class doesn't provide any useful abstraction and the code gets obfuscated by all the wrapper methods. Moreover it's mixed with real changes so very hard to review. Can't you just fix what needs to be fixed first? -- Eric Botcazou
