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>
- Cc: GCC Development <gcc at gcc dot gnu dot org>
- Date: Fri, 10 Oct 2014 12:18:11 -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> <54381DCA dot 10805 at redhat dot com> <CAFULd4aUpzoakgaRkGP24Yy5KV2Le9iQgDM_7bWoX79yfMOTdg at mail dot gmail dot com>
On 10/10/14 12:12, Uros Bizjak wrote:
Right. And my question is what happens if we aren't as aggressive here.
What happens if before this check we return nonzero if X or Y is a
VALUE? Do we then get into memrefs_conflict_p and does it do the right
On Fri, Oct 10, 2014 at 7:56 PM, Jeff Law <email@example.com> wrote:
On 10/09/14 06:14, Uros Bizjak wrote:
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
via AND, there is no conflict. We can bring knowledge of object
alignment into play here. For example, on alpha, "char a, b;" can
But when base_alias_check returns, we call memrefs_conflict_p which does
know how to dig down into a VALUE expression.
IIRC, the problem was that base_alias_check returned 0 due to:
/* Differing symbols not accessed via AND never alias. */
if (GET_CODE (x_base) != ADDRESS && GET_CODE (y_base) != ADDRESS)
so, the calling code never reached memrefs_conflict_p down the stream.
Yea, but I'm slammed right now and won't be able to look at it under a
debugger for a while.
It might be that targets without AND addresses are immune to this
issue, but the code that deals with ANDs is certailny not prepared to
(The testcase from the PR can be compiled with a crosscompiler to
alpha-linux-gnu, as outlined in the PR. Two AND addresses should be
detected as aliasing, but they are not - resulting in CSE propagating
aliased read after store in (insn 29).)