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

[kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)]

    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.

Interesting idea.  Probably worth it, though.

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

OK, but array_ref_element_size looks at that field only if it's set.
Before gimplification, it's not and it returns the actual element size.
Are Fortran's plans consistent with that?

    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.

Using TYPE_ALIGN doesn't work because you don't know whether all the fields
in the path are aligned that way.  They might be "bit fields" that are
misaligned.  Before highest_pow2_factor and the MEM_ALIGN addition, we used
to get this wrong a lot.  Now we are very precise.

Also, the whole point of what I did is that highest_pow2_factor *will* see
the multiply!  get_inner_reference will call array_ref_element_size which
will generate the multiplication (in the variable case).

    > Right.  It doesn't seem worth the trouble here.

    Meaning the comment is incorrect.

I'll go back and look at the code, but I think I just copied the comment,
and didn't add it ...

    > 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.

Sure, but by that argument we can allow <PLUS_EXPR <MULT_EXPR ....>> in
GIMPLE!  My point is that REALPART_EXPR and IMAGPART_EXPR have inputs and
outputs that are both scalars, so it would seem more in keeping with
the GIMPLE strategy to not mix them with other operations.

    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?

Good point.  I'll have to investigate that again.  If my memory is
correct, this was motivated by a C or C++ testcase, not Ada.

    > 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.

Oh!  If you'd said stmt_p, I would have known what you meant.  Yes, I
think you're right: I'll change that.

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

OK.