This is the mail archive of the
mailing list for the GCC project.
Re: RTL infrastructure leaks VALUE expressions into aliasing-detecting functions
- From: Jeff Law <law at redhat dot com>
- To: Uros Bizjak <ubizjak at gmail dot com>, GCC Development <gcc at gcc dot gnu dot org>
- Date: Fri, 10 Oct 2014 11:56:26 -0600
- Subject: Re: RTL infrastructure leaks VALUE expressions into aliasing-detecting functions
- Authentication-results: sourceware.org; auth=none
- References: <CAFULd4ZJwrxFjcHBDgg=zzztQXxSmA3_OjjmkGhYKfEppZ2cxQ at mail dot gmail dot com>
On 10/09/14 06:14, Uros Bizjak wrote:
But when base_alias_check returns, we call memrefs_conflict_p which
does know how to dig down into a VALUE expression.
I'd like to bring PR 63475 to the attention of RTL maintainers. The
problem in the referred PR exposed the RTL infrastructure problem,
where VALUE expressions are leaked instead of MEM expresions into
various parts of aliasing-detecting support functions.
As an example, please consider following patch for base_alias_check:
--- alias.c (revision 216025)
+++ alias.c (working copy)
@@ -1824,6 +1824,13 @@ base_alias_check (rtx x, rtx x_base, rtx y, rtx y_
if (rtx_equal_p (x_base, y_base))
+ if (GET_CODE (x) == VALUE || GET_CODE (y) == VALUE)
+ debug_rtx (x);
+ debug_rtx (y);
+ gcc_unreachable ();
/* The base addresses are different expressions. If they are not accessed
via AND, there is no conflict. We can bring knowledge of object
alignment into play here. For example, on alpha, "char a, b;" can
Is it simply the case that we want/need to consider anything with a
VALUE as not passing the base alias check and defer memrefs_conflict_p?
I really don't know, it's been a long time since I worked with this code
(it predates the introduction of cselib, so that gives you an idea of
how long its been :-)