PATCH Re: [ast-optimizer-branch] gcc.dg/struct-alias-1.c failure
Jason Merrill
jason@redhat.com
Tue Jun 11 17:42:00 GMT 2002
>>>>> "Diego" == Diego Novillo <dnovillo@redhat.com> writes:
> We are now failing struct-alias-1.c because we don't do constant
> propagation on trees. The simplifier is turning:
> s.x = 0;
> if (s.x != 0)
> link_error ();
> into
> s.x = 0;
> T.2 = s.x;
> if (T.2 != 0)
> link_error ();
> which confuses the RTL constant propagator.
The test isn't that simple; there's another store in the middle. So,
s.x = 0;
s.a[i] = 1;
if (s.x != 0)
link_error ();
becomes
s.x = 0;
T.1 = &s.a;
(*T.1)[i] = 1;
T.2 = s.x;
if (T.2 != 0)
link_error ();
Also, it's not cprop that's getting confused, it's alias analysis. In the
unsimplified code, the backend can see that the second store is to a
different member of s, so it won't conflict with the store we already saw;
in the simplified code, the struct member reference has been factored out,
so the alias analysis code doesn't see it.
This is exactly what rth was talking about; he argues that we shouldn't
separate the array and member references. Until alias analysis improves, I
think I agree. I've attached a patch. In this patch I've commented out
the code for handling arrays and structs separately, as we might want to
switch back once alias analysis is more clever.
In the array simplification function, you made an effort to simplify the
bounds in left-to-right order. Why? It would seem more efficient to
simplify them in right-to-left order, as that way the first one used in
calculation will be the one most recently calculated. It's also simpler to
code that way.
OK?
Jason
2002-06-12 Jason Merrill <jason@redhat.com>
* tree-simple.c (is_simple_compound_lval): New fn.
(is_simple_varname): Call it instead of is_simple_arrayref and
is_simple_compref.
(is_simple_arrayref, is_simple_compref): Comment out.
* tree-simple.h: Declare it.
* c-simplify.c (simplify_expr_either): Comment out.
(simplify_compound_lval): New fn.
(simplify_array_ref, simplify_component_ref): Just call it.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/x-patch
Size: 8815 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc/attachments/20020611/b7c9a2d2/attachment.bin>
More information about the Gcc
mailing list