More on gimplify:create_tmp_var

[Jason Merrill]

On Sun, 6 Jun 04 13:47:44 EDT, kenner@vlsi1.ultra.nyu.edu (Richard Kenner) wrote:

> For access efficiency, we want to nest ARRAY_REF, COMPONENT_REF, and
> the other references.  These are all handled in get_inner_reference as
> a single access, by merging all the offsets.  So *anything* that it can
> handle should be gone "inside" by this routine.

I'm somewhat dubious.  That gimplify_compound_lval currently allows nested
references is due to limitations of the old alias engine, whereby taking
the address of a member and then using that for further references caused
us to lose track of the object that it came from.  We need to handle this
sort of thing for explicit user code, and it seems better to me to do it in
the gimplifier as well, to expose more common subexpressions.  We should be
able to merge the offsets later in the optimization process.

>     I think you should be generating <INDIRECT_REF <NOP_EXPR <VAR>>>
>     instead of using VIEW_CONVERT_EXPR after the fact.
>
> That seems *far* worse.  Because then the INDIRECT_REF will *have* to
> make a temporary and that temporary is often variable-sized.  It seems
> we'd have lots of copies.

We make a pointer temporary for the NOP_EXPR, not the INDIRECT_REF.

> The point is that a very deep nest of COMPONENT_REF, VIEW_CONVERT_EXPR,
> and ARRAY_REF is quite common in Ada.  We don't need to make a temporary
> (or want to) of any of the aggregates in between.  We also don't want to
> take their address since they are non-addressable.

They're non-addressable?

Jason