Re: [patch] for PR 18040

[Zack Weinberg <zack at codesourcery dot com>]

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

>       return ((r *) &var)->f1 + var[2000];
>
> As I said earlier, that works *in this case*, but not in the general
> case of nested field references, because you might be needing to
> take the address of something non-addressable and ...
>
>     This does not look very different from what you are generating
>     now, but sandwiching the cast inside an address-of and
>     dereference means that the gimplifier can break it down without
>     needing to create an aggregate temporary, producing something
>     like this:
>
> But you *would* need the aggerate temporary in the nested reference
> case, which is the general case.  I don't see a strong argument for
> doing something special for the degenerate case here.

I talked about the unnested case because I had forgotten that the
nested case existed, so I assumed that the example you gave was the
most general case.  As I said earlier, I would have appreciated being
shown an example not amenable to a solution which has already been
ruled out.

Your opinion on my alternative suggestion - hoist the type conversion
to the outermost type, thus reducing the nested case to the unnested
case - would be appreciated (and please read the whole message before
answering the question, because I address another objection below).

>     The only catch is that alias analysis must understand that rp
>     aliases var.  This may require some adjustment to GNAT's alias
>     set logic.
>
> If it did, then it couldn't be done because the types and the
> unchecked conversion could be in different translation units, so you
> can't know the unchecked conversion existed when you were assigning
> alias sets to the types.

I didn't say this had to be captured in the type-based alias sets, I
said it had to be comprehensible to the alias analyzer.  Those two
assertions are not the same thing.

In particular, I'm guessing that the unchecked_conversion operation
needs to be visible at the point that its result is *used*; otherwise
you would be forced to make extremely conservative aliasing
assumptions about all pointers or references whose initialization was
not visible, and I doubt this is the case.  Thus, you could use
flow-based alias analysis to get it right.

> This stuff is *very* tricky and, as I said, we've been throught it
> before.

The PR indicates that the solution which has already been implemented
does not work.  Thus, the entire topic is open for reexamination.

zw