This is the mail archive of the
mailing list for the GCC project.
r242089 - /branches/ARM/sve-branch/gcc/alias.c
- From: rsandifo at gcc dot gnu dot org
- To: gcc-cvs at gcc dot gnu dot org
- Date: Fri, 11 Nov 2016 16:57:42 -0000
- Subject: r242089 - /branches/ARM/sve-branch/gcc/alias.c
Date: Fri Nov 11 16:57:42 2016
New Revision: 242089
Add a mem_alias_size helper class
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
(mem:SI (const_int X))
(mem:SI (symbol_ref Y))
(mem:SI (const (plus (symbol_ref Y) (const_int 4))))