On 10/10/14 12:12, Uros Bizjak wrote:
On Fri, Oct 10, 2014 at 7:56 PM, Jeff Law <l...@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
