More on c-gimplify.c:gimplify_decl_stmt

[Richard Kenner]

    They are most certainly NOT constant.  If they were constants, they'd
    be INTEGER_CST objects.  And they ABSOLUTELY POSITIVELY do need to be
    visible to the optimizers.  Failure to do so results in wrong answers,
    not some sort of lack of optimization.

I didn't mean literally constants, I meant constants for a definable region
of the program.  More specifically, for the lifetime of the object in
question.  Let's call them "unchanging".

    We started out with an implicitly referenced variable feature on 
    tree-ssa branch and it caused no end of problems.  It's gone now,
    and it won't return.

Well, it seems that decision might have been too hasty because it ignored
this hard problem.

    I think we have all we need for aliasing and loop information,
    actually.  We have numbers that say how far we are from the beginning
    of the object, and what the alignment is.  What more is there?

The name of the fields being referenced for the aliasing case and the fact
that there's an array at all for the loop case.

Knowing that one reference is 1250 bytes from the start of A and another is
1572 bytes from the start of B doesn't say they can't alias.  Saying that the
first reference uses field F1 of a type and the second reference uses field
F2 of that same type says they can't alias.  That's an important optimization
(indeed, isn't it one that you added?).  You'd lose that.  You also no longer
can be precise as to the alias set when you go down to RTL because you
lose the typing information of the field.

As to loop optimization, you can easily have an array inside a record.  If all
you see if a position into a record, it's a lot of work to deduce that it's
an array index.

    Haha.  Early or late, these objects are at variable offsets.  That
    is way outside any scalarization I ever plan to implement.

I don't follow.  Yes, they are "variable", but they are unchanging for the
life of the object.  So the *normal* scalarization would work just fine for
them, with no special handling.

    If someone else wanted to tackle it some day, I don't see that they'd
    have lost any information except for the name of the field.  Which is
    basically irrelevant.

I thought the whole point of the scalarization was to use the fact that
it was a field.