[tree-ssa]: Invalid GIMPLE generated by C++ front end

[Daniel Berlin]

On Wednesday, August 13, 2003, at 4:52 PM, Jason Merrill wrote:

> On Wed, 13 Aug 2003 15:53:41 -0400, Daniel Berlin 
> <dberlin@dberlin.org> wrote:
>
>> I've been seeing expressions like  T.2 = (char * const &)&<UVbbd0>
>> generated by the C++ FE lately (compiling string-inst.cc on darwin, 
>> for
>> instance).
>>
>> Are these actually valid GIMPLE?
>
> No.  I ran into a similar crash recently; the problem turned out to be 
> with
> the inliner inserting nops during &* elimination.  I've attached a 
> patch
> below.  Does it fix your bug?


Bootstrapping now.

>> Going by the grammar, they aren't, and they are causing PTA to miss 
>> some
>> variables because they fail is_gimple_modify_expr.
>
> Incidentally, I'm in the process of converting all of the 
> gimplification
> predicates to only check the tree code in most cases, since that's all 
> I
> care about during gimplification.  The underlying nodes will already 
> have
> been massaged into the right form by recursive gimplification.
>
> But your comment brings up the possibility that other passes will want 
> to
> be able to check whether or not a transformation leaves the code in 
> gimple
> form.  Is this what you need?

Yup. But not for PTA.
Forward, substitution, for instance, can only substitute when the 
resulting expression is still in GIMPLE form.

IE forward subst takes something like

k = q + 3
t = k + 9
a[t] = blah + blah
and makes it
a[q + 12] = blah + blah
(It's a loop pre-transformation to make dependence analysis and whatnot 
easier)
We can't do this if we had something like:

k = q + b
t = k + 9
a[t] = blah + blah
because
a[q + b + 9] = blah + blah
is not valid GIMPLE.



> If so, would calling back into gimplify_expr
> be a reasonable alternative (if it worked)?

Well, in this case, no, because we just don't want to perform the 
transform at all if we can't make it come out as a GIMPLE expression. 
If we re-gimplified, we'd end up with the same thing we started with!