llvm dev - Nov 2020 - LLVM Alias Analysis Technical Call

A friendly reminder that we'll have our monthly alias analysis technical 
call on Tuesday, November 3rd, noon central time.

Agenda, calendar invite, and call-in information can be found here:

https://docs.google.com/document/d/1ybwEKDVtIbhIhK50qYtwKsL50K-NvB6LfuBsfepBZ9Y/edit?usp=sharing

Hope to see you there,
   Johannes

The call will start in ~50 minutes. The calendar invite (.ics) is 
attached to this mail.

On 11/1/20 10:00 PM, Johannes Doerfert wrote:
> A friendly reminder that we'll have our monthly alias analysis 
> technical call on Tuesday, November 3rd, noon central time.
>
> Agenda, calendar invite, and call-in information can be found here:
>
>
https://docs.google.com/document/d/1ybwEKDVtIbhIhK50qYtwKsL50K-NvB6LfuBsfepBZ9Y/edit?usp=sharing
>
>
> Hope to see you there,
>   Johannes
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: invite.ics
Type: text/calendar
Size: 1616 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20201103/a3499a67/attachment-0001.ics>

On Mon, Nov 2, 2020 at 5:00 AM Johannes Doerfert via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> A friendly reminder that we'll have our monthly alias analysis
technical
> call on Tuesday, November 3rd, noon central time.
>
> Agenda, calendar invite, and call-in information can be found here:
>
>
>
https://docs.google.com/document/d/1ybwEKDVtIbhIhK50qYtwKsL50K-NvB6LfuBsfepBZ9Y/edit?usp=sharing
>
> Hope to see you there,
>    Johannes
>
Hi,

I probably won't make it to the call, so I want to leave some thoughts here
on two related topics.

The first is the fact that LLVM is currently miscompiling noalias
attributes/metadata, tracked at https://bugs.llvm.org/show_bug.cgi?id=39282.
This is a long-standing problem with a simple solution, implemented in
https://reviews.llvm.org/D90104. The only reason (I assume) we haven't done
this before, is that this solution is slightly non-optimal (in the sense of
optimization quality). The "full restrict" patch set has been
presented as
the optimal solution to this problem. However, the full restrict patch set
has been stalled for a long time.

I would like to make sure that this problem gets addressed in LLVM 12. I
think it's unlikely that the full restrict patches will fully land by that
time, so I believe this requires a more targeted fix -- yes, even if it may
reduce optimization quality. It should go without saying that optimization
correctness trumps optimization quality. (If this problem is not addressed
by LLVM 12, we should probably discard "restrict" qualifiers in Clang
completely until this issue can be resolved.)

And that brings me to the second topic: I looked at the LangRef patch (
https://reviews.llvm.org/D68484) of the full restrict proposal a while ago,
and have to admit that this proposal is beyond me. There are a lot of parts
to it, and while the purpose of some are clear, I don't fully understand
how it all fits together and why it looks exactly like it does. I think it
will be hard to get the design approved in the current form, as it would
require multiple reviewers to fully understand it, and be convinced that
this is truly the simplest way to meet all the design constraints.

The full restrict support is currently broken up into multiple patches,
where each patch basically implements support for the whole machinery in
some particular part of the compiler. To make progress here, I think it may
be more productive to split this up in a different way: To introduce
individual parts of the machinery independently, to the degree that this is
possible. This should make review much easier, and thus will hopefully
allow it to finish in a finite amount of time :) It also helps to clarify
precisely what problem each part is solving, and allows the design of each
part to be scrutinized in detail.

As I mentioned on https://reviews.llvm.org/D90104, a good first part to
introduce separately would be the @llvm.noalias.decl intrinsic. This is the
part that is necessary to solve the loop unrolling problem with full
accuracy. I think this intrinsic is rather independent from the rest of the
proposal, has an obvious problem that it solves and a simple design -- this
is something where we should be able to make progress quickly.

I'm not sure which part would be best to handle after that. I would take a
look at which part of the proposal are needed to make basic local restrict
variables work, without support for non-trivial reassignments of the
restrict variable and without support for restrict in structs. I expect
that quite a few bits (like llvm.noalias.arg.guard) are not necessary for
baseline support.

Regards,
Nikita
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20201103/23dc2d56/attachment.html>