This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PR55547] fix alias regression on alpha on misaligned symbols
- From: Alexandre Oliva <aoliva at redhat dot com>
- To: Richard Henderson <rth at redhat dot com>
- Cc: ubizjak at gmail dot com, Aldy Hernandez <aldyh at redhat dot com>, gcc-patches at gcc dot gnu dot org
- Date: Thu, 17 Jan 2013 00:40:45 -0200
- Subject: Re: [PR55547] fix alias regression on alpha on misaligned symbols
- References: <50F582CE.3090201@redhat.com> <50F585DB.2020706@redhat.com> <orlibt6995.fsf_-_@livre.localdomain> <50F70571.3080606@redhat.com>
On Jan 16, 2013, Richard Henderson <rth@redhat.com> wrote:
> I notice that these expressions (including the first hunk that uses
> ifs) are now all the same.
*nod*
> It would seem extremely prudent to pull
> this out to a function so that they stay the same.
ack, will do.
> That said, I question the change of <= to == 0. If negative, we don't
> know how much overlap there is as far as I can see.
Why not? Since the addresses are constants, and the negative sizes are
just the adjusted sizes, negated to indicate they were conservatively
lengthened by an alignment operation, we can determine that two
references don't overlap if they're far enough from each other that,
even with the alignment adjustment, they're still clearly
non-overlapping. Say, if x is 0x0fff and y is 0x1234, both originally
referenced with size 8 and x aligned to 0x20, it is obvious that the
accesses won't overlap, in spite of the alignment on x. The test
applied on constant addresses wouldn't realize that and would say they
could overlap, because any alignment-adjusted size would be mistaken as
âoverlaps with anythingâ.
>> if (GET_CODE (x) == CONST)
>> @@ -2139,7 +2141,8 @@ memrefs_conflict_p (int xsize, rtx x, int ysize, rtx y, HOST_WIDE_INT c)
>> if (CONSTANT_P (y))
>> return (xsize <= 0 || ysize <= 0
>> || (rtx_equal_for_memref_p (x, y)
>> - && ((c >= 0 && xsize > c) || (c < 0 && ysize+c > 0))));
>> + && ((c >= 0 && abs (xsize) - c > 0)
>> + || (c < 0 && abs (ysize) + c > 0))));
> This hunk is not needed, as we begin by eliminating <= 0. So the abs
> is certain to do nothing.
The function I'll introduce to keep the expressions the same will have
the abs and I'll use it here, but you're right that after testing for
negative sizes they abses won't make much of a difference.
--
Alexandre Oliva, freedom fighter http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/ FSF Latin America board member
Free Software Evangelist Red Hat Brazil Compiler Engineer