Re: determining aggregate member from MEM_REF

[Richard Biener <richard.guenther@gmail.com>]

On Mon, Feb 26, 2018 at 9:04 PM, Jeff Law <law@redhat.com> wrote:
> On 02/26/2018 08:44 AM, Martin Sebor wrote:
>>
>> Folding things to MEM_REF (or rather, folding them too early)
>> makes all kinds of analysis harder: not just warnings but even
>> optimization.  I've raised a whole slew of bugs for the strlen
>> pass alone where folding string functions to MEM_REF defeats
>> useful downstream optimizations.  Making strlen (and all other
>> passes that might benefit from the original detail) work hard
>> to deal with MEM_REF isn't a good design solution.  It forces
>> the complexity that MEM_REF is meant to remove back into its
>> clients.  Worse, because of the loss of detail, the results
>> are unavoidably suboptimal (at least for certain kinds of
>> analyses).
> I haven't looked specifically at the MEM_REF folding, but I wouldn't be
> surprised to find cases where deferral ultimately results in regressions.

MEM_REF was introduced to fix representational shortcomings, not
mainly to make the representation more compact.  For example there
wasn't a way to recod that an access is volatile or un-aligned without
taking the address of sth, casting that thing and then dereferencing it.
That causes havoc in alias-analysis because many more things are
now addressable.  Also it was introduced to fix wrong-code bugs but
at the same time not cause missed optimizations.  That's when
propagating "structural addresses" into dereferences which is
generally invalid if you preserve the structure of the address.

With losing some of the canonicalization we could allow
MEM[&a.b.c.d, + 5] instead of forcing the .b.c.d into the constant
offset.  Or we could add a third operand so we have MEM[&a, +10, &a.b.c.d]
or so.  But all that comes at a cost and cannot solve all the issues
so I'm hesitant to do sth (costly) like that.

> When to fold & lower is a hard problem.  There is a constant tension
> between trying to fold early as it often leads to generally better code
> vs folding later which may help other sets of code, particularly when
> folding results in an inability to recover data.
>
> There generally is not an optimal solution to these problems; we have to
> take a pragmatic approach.  So if you can defer and not regress, then by
> all means propose patches.  But I think you'll find that to defer means
> you have to beef up stuff later in the pipeline.

Note we already do defer some stuff - not that I like that - but ultimately
you get to the point where defering hinders exactly the optimization you
want to perform to get good diagnostics.  So it remains a chicken-and-egg
issue.

Defering to a reasonable point also means that by practical means you
could have done a proper IPA static analysis pass in the first place.

Richard.

> jeff