Re: More on gimplify:create_tmp_var

[Jason Merrill <jason at redhat dot com>]

On Wed, 9 Jun 2004 14:15:19 -0400, Geert Bosch <bosch@gnat.com> wrote:

> On Jun 9, 2004, at 13:38, Jason Merrill wrote:
>>> 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?
>
> In the most general case they are non-addressable, as one may
> have a packed array of booleans for example. Keeping these
> as regular array references has the benefit that it becomes
> easy to tell that stores to A (3) and A (5) are independent.
> Once this get expanded to byte/word loads, mask operations
> and writes, this becomes very hard to tell. Furthermore,
> deciding what types to use for expansion depends on the target
> machine.

Sure, but this should only apply to the innermost ref.

> In almost all cases, components of composite types (records/arrays)
> cannot be aliased by pointers in the user's code. This is similar
> to Fortran. If we would flatten these references in the front end,
> we would loose all the aliasing information. If we're accessing
> field F of record type R in two places, we may not be able to
> disambiguate these aliases. However, accesses to P.R.F and Q.R.F
> are clearly independent.

The point I was making earlier in my message was that we should be smart
enough to know that given

  R* pr = &p.r;
  R* qr = &q.r;

pr->f and qr->f are independent.  I don't think this day is far off, if
indeed we aren't already there.

Jason