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/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.

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 :-)

jeff



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