This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [tree-ssa] Out of SSA status and issues
On Tue, 2003-05-13 at 09:29, Andrew MacLeod wrote:
> >
> > 1. foo()
> > 2. {
> > 3. int *p;
> > 4.
> > 5. p_1 = malloc();
> > 6. p_4 = malloc();
> > 7. return *(p_1)_3 + 9;
> > 8. }
> >
> > Will the coalescer DTRT here? Yes, it's a silly transformation, but I'm
> > wondering if we don't have a bigger problem here. I've been toying with
>
> Sure, the coalescer will handle this easily. p_1 and p_4 conflict, so
> they will get assigned something like:
>
> p = malloc ()
> p.33 = malloc()
> return *p + 9
>
Excellent.
> Doesn't make the copy-prop example right tho.
>
What example? The one I gave with 'p = malloc()' or the one you had
with 'T.6'? I already agreed that copyprop in the case of your example
code was wrong, *T.6 is aliased, right? In which case, we should never
see *T.6 in a real operand. If we do, then we have a bug in
get_stmt_operands.
> If you take the original case, and use the new format, you'd get:
>
> # (*T.6_12)_13 = VDEF <(*T.6)_7>;
> T.6_12 = T.2_8 + T.5_11;
>
> # VUSE <T.6_12>;
> i_14 = (*T.6_12)_13 <<<--- This is an issue....
>
> # (*T.6_12)_22 = VDEF <(*T.6_12)_13>
> # VUSE <T.6_12>
> *T.6_12 = 30;
> };
> # i_1 = PHI <i_6(0), (*T.6_12)_13(1)>;
>
Wait. The above is wrong. On some statements you have *T.6 in VDEF
operands, and in 'i_14 = (*T.6_12)_13' you have it as a real operand.
Did we really rename the program like that? Is *T.6 aliased? If so,
then we have a different problem. Aliased references should always be
voperands.
Now, let's assume for a minute that the code above didn't use pointers.
I'll replace uses of *T.6 with J:
i_14 = J_13;
J_12 = 30;
};
# i_1 = PHI <i_6(0), J_13(1)>;
The above transformation should be OK, right? The point I've been
trying to convey is that if we now changed J for an UNALIASED pointer
dereference '*p', then the trasnformation should also be valid:
i_14 = *(p_3)_13;
*(p_3)_14 = 30;
};
# i_1 = PHI <i_6(0), *(p_3)_13(1)>;
The copies that the coalescer must insert are exactly the same, right?
It needs to create a temporary to hold the value of *(p_3)_13. We know
that we are referencing the same memory location p_3 and that memory
location is not aliased, because all references to *p appear as real
operands.
What am I missing? I agree that we should not do this for performance
reasons. I'm merely trying to figure out if treating INDIRECT_REFs as
first-class variables is doable as I think it is. It would certainly be
easier for me to punt and treat them as regular expressions and let
SSAPRE deal with them.
> I don't think it should have the _13. And of course, the VUSE shouldn't
> be there since T.6_12 is now a real use. In fact, the aliased variable
> should be a VUSE... so I think it ought to look like:
>
> # VUSE <(*T.6_12)_13>
> i_14 = *T.6_12
>
Yes. I'm surprised it doesn't. Send me a test case?
Diego.