RTL infrastructure leaks VALUE expressions into aliasing-detecting functions

[Jeff Law]

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