What to remove after tree-ssa is merged?

[Richard Kenner]

    Or are P_E in types also used to actually influence code generation 
    (instead of P_E just in expressions/statements).  And in that case: why is 
    this so, and why are P_E in statements not usable for this?

I'm not sure I understand what you mean.

PLACEHOLDER_EXPR describes a fundamental property of the type from an
implementation standpoint: that in order to compute an offset or size you
need to look inside an object of that type at runtime for a value and use
that value in the computation.

"code generation", of course, is ambiguous here since it's not clear if it
means generation of code trees or RTL.

It's certainly needed for the former and may be needed for the latter.

    FWIW I know that you indeed need this treecode somewhere, it's just
    the question if it needs to be in GIMPLE, and hence has to be handled
    by the middle end, or if it can be isolated to the frontend.

I don't know GIMPLE, so I can't answer that question, but the issue is when
are COMPONENT_REFs lowered?  Because that's when these are used.

A classic case is a record that has two variable-sized arrays, where the
bounds of the arrays are a function of "discriminants", which are other
(earlier) fields in the record.  Consider the second array.  Its
DECL_FIELD_BITPOS will be a function of a PLACEHOLDER_EXPR whose type is the
record in question.

If you have an ARRAY_REF of a COMPONENT_REF pointing into that second array,
the offset needed will depend on a PLACEHOLDER_EXPR.  However, we can
probably get rid of WITH_RECORD_EXPR.  Instead, we can recompute the tree at
that point to do the same substitutions at that point that now happen when
RTL is generated.  The reason this wasn't done before was to avoid the extra
memory since it could easily be done at RTL generation time.  But here, we
don't want to do that.