This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RTL infrastructure leaks VALUE expressions into aliasing-detecting functions


On 10/10/14 12:12, Uros Bizjak wrote:
On Fri, Oct 10, 2014 at 7:56 PM, Jeff Law <law@redhat.com> wrote:
On 10/09/14 06:14, Uros Bizjak wrote:

Hello!

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:

--cut here--
Index: alias.c
===================================================================
--- 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))
       return 1;

+  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

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)
     return 0;

so, the calling code never reached memrefs_conflict_p down the stream.
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 thing?




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
handle VALUEs.

(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).)
Yea, but I'm slammed right now and won't be able to look at it under a debugger for a while.

jeff


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]