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
--cut here--

The crosscompiler to alpha-linux-gnu dies immediately on the testcase,
provided in the PR.

One of the checks that trigger this condition in base_alias_check is:

(and:DI (lo_sum:DI (reg/f:DI 13 $13 [72])
        (symbol_ref:DI ("aaa") [flags 0x6]  <var_decl 0x2b66ff7cb000 aaa>))
    (const_int -8 [0xfffffffffffffff8]))

with

(value:DI 7:3304360 @0x1b619ee0/0x1b614cb0)

and this is the reason why aliasing of aaa and bbb is not detected.
The (VALUE) RTX corresponds to:

cselib value 7:3304360 0x8a84cb0 (and:DI (lo_sum:DI (reg/f:DI 11 $11 [78])
        (symbol_ref:DI ("bbb") [flags 0x6]  <var_decl 0x2b2ff8af6090 bbb>))
    (const_int -8 [0xfffffffffffffff8]))

so, there is no way for current code to detect aliasing between these two RTXes.

Reply via email to