Re: Patch to allow Ada to work with tree-ssa

[Richard Henderson <rth@redhat.com>]

On Tue, Jun 22, 2004 at 09:59:23AM -0400, Richard Kenner wrote:
>     >     if (stmt == NULL_TREE)
>     > -     stmt = build_empty_stmt ();
>     > +     stmt = alloc_stmt_list ();
> 
>     Huh?
> 
> Empty statement lists will do away when being inserted into another
> statement list: empty statements won't.

If we're going to change anything here, I'd prefer that the
gimplifier handle NULL as an empty statement.  Then we don't
have to allocate anything or merge anything.

>     I wonder if "stride" might be a better term than "size"?
> 
> Perhaps.  It's more descriptive in a technical sense.  But it does
> come from the SIZE value, so that's the counterargument.  I don't object
> to changing it.

I should have been more clear.  Fortran has plans to use this
field for stride different than size.

> It's required that get_inner_reference make that multiplication so
> that it can use highest_pow2_factor for proper alignment tracking.

Not really.  There are only two things that highest_pow2_factor is
going to see given gimple input: a constant or variable times 
constant.  Which means that you can just as well use the TYPE_ALIGN
when given a non-constant.

>     Please don't add unnecessary forward declarations.
> 
> "unncessary"?  The convention is to have them all there.

Back when we were writing in K&R C and it was necessary.
The convention has changed since then.

>     Well, we certainly *can* give gimplify_conversion the pre-queue from
>     gimplify_expr, but it seems unlikely that we'll necessarily see that
>     non-constant lower-bound and generate (symbol_ref array).  I.e. 
>     avoid all arithmetic when we get to the rtl level.
> 
> Right.  It doesn't seem worth the trouble here.

Meaning the comment is incorrect.

> Because get_inner_reference doesn't support IMAGPART_EXPR and REALPART_EXPR.
> It seemed cleaner to break up the two cases since they are handled
> differently.

I disagree.  It's just another accessor.  Feed the whole lot to
expand_expr and you'll get the right answer anyway.

>     I don't understand what you're doing here.  In what way could you 
>     have not already gimplified these references?
> 
> It's the case where the "statement" is a reference to a component of
> volatile.

So you've got a reference a.b.c.d.e in which, say, b is volatile?
So why are you removing the c.d.e bits of the componentry, so that
you access more of b than the user intended?

> I'll have to investigate that: I never heard of list_p.

Yes you have.  It's the list argument to append_to_statemnt_list.
Meaning taking a "tree *" in which to put statements is a better
option than returning a statement list.

>     It is incorrect to give gimplify_expr a post-queue here, because
>     *expr_p is going to be used after *stmt_p.  Either gimplify_expr
>     will find a workaround for the missing post-queue, or we'll abort.
>     As it is we'll generate incorrect code.
> 
> Oh, right.  I'll abort.

No, you don't abort, gimplify_expr aborts.   Just don't provide
the post queue.


r~