Re: [patch] for PR 18040

[Zack Weinberg <zack at codesourcery dot com>]

kenner@vlsi1.ultra.nyu.edu (Richard Kenner) writes:

>     Hmm.  Is it possible to construct an example which BOTH requires
>     taking the address of an intermediate field, and wouldn't be cured by
>     making all *_REF expressions implicitly convert to their type?
>
> Sorry, I didn't realize that you were talking about a different solutions
> to each problem.

Well, at the time I had forgotten about the intermediate-field case,
but I think that two different solutions might well be appropriate.

> I believe the answer to the question you pose is "no", but it's
> going to be hard to prove that.  There is a potential aliasing
> problem, but I don't think it can actually occur because you can
> always view the semantics of the VIEW_CONVERT_EXPR as being pointer
> punning and could make the resulting pointer TYPE_REF_CAN_ALIAS_ALL.

Ok.  Does that also address the objection you raised to the
pointer-punning operation at the outermost level?

>     Also, I just now thought of an alternative: whenever you have a chain
>     of *_REF expressions which requires a type conversion somewhere along
>     the way, construct a modified version of the *outermost* type which
>     will give the field in question the effective type that it needs.
>
> That construction operation is linear in the number of fields in the
> record.  If you have a program that access each field, doing that
> construction produces quadratic behavior (we have such a program in
> the testsuite for simple field accesses).

You'd only need to construct the modified outermost type when you had
a type conversion somewhere along the chain of references.  I suppose
one could construct a program that accesses each field *with* a type
conversion; I can't think of any good reason such a program would pop
up in the wild, but still, if we can find a solution that doesn't
entail quadratic behavior for this case that would be good.

> What I'm not sure about are issues relating to code quality: we've
> taken what used to be expanded as one operation between tree and RTL
> and converted it into four distinct operations (ADDR_EXPR, NOP_EXPR,
> INDIRECT_REF, and COMPONENT_REF) and it'll be up to the RTL
> optimizers to put it all back together.
>
> I think it's taking a step backwards when we can no longer represent
> what is a single expansion operation in GIMPLE as one statement.

Experimentally speaking, the C example I showed you compiles to
exactly the same code as the Ada example.  So the optimizers are
effective at putting it all back together.  That's not a very
complicated example, of course.

Now I'm not the person to make final judgements about design criteria
of GIMPLE; my involvement in the tree-ssa project has been minimal.
However, I think this is a mistaken design rationale.  The goal of
GIMPLE as I understand it is to be simple, logically consistent, and
both language- and machine-independent (by which I mean that all
language- and machine-specific semantics are encoded explicitly in the
representation, rather than referring to 'hooks' into front or back
end).  The goal is not to be able to represent as one statement every
operation that can be encoded in one machine instruction, and it is
certainly not to be able to represent as one statement every primitive
operation of every supported language.

In this case, it seems to me that it may well be better overall to
translate this particular language operation to multiple GIMPLE
statements even though it is going to wind up being compressed back
down to one machine instruction, since that seems to make life so much
easier for both the optimizers and the humans trying to debug the
optimizers.

zw