<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Nov 2, 2020 at 5:00 AM Johannes Doerfert via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">A friendly reminder that we'll have our monthly alias analysis technical <br>
call on Tuesday, November 3rd, noon central time.<br>
<br>
Agenda, calendar invite, and call-in information can be found here:<br>
<br>
<a href="https://docs.google.com/document/d/1ybwEKDVtIbhIhK50qYtwKsL50K-NvB6LfuBsfepBZ9Y/edit?usp=sharing" rel="noreferrer" target="_blank">https://docs.google.com/document/d/1ybwEKDVtIbhIhK50qYtwKsL50K-NvB6LfuBsfepBZ9Y/edit?usp=sharing</a><br>
<br>
Hope to see you there,<br>
   Johannes<br></blockquote><div><br></div><div>Hi,</div><div><br></div><div>I probably won't make it to the call, so I want to leave some thoughts here on two related topics.</div><div><br></div><div>The first is the fact that LLVM is currently miscompiling noalias attributes/metadata, tracked at <a href="https://bugs.llvm.org/show_bug.cgi?id=39282" target="_blank">https://bugs.llvm.org/show_bug.cgi?id=39282</a>. This is a long-standing problem with a simple solution, implemented in <a href="https://reviews.llvm.org/D90104" target="_blank">https://reviews.llvm.org/D90104</a>. 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.<br></div><div><br></div><div>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.)</div><div><br></div><div>And that brings me to the second topic: I looked at the LangRef patch (<a href="https://reviews.llvm.org/D68484" target="_blank">https://reviews.llvm.org/D68484</a>) 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.</div><div><br></div><div>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.</div><div><br></div><div>As I mentioned on <a href="https://reviews.llvm.org/D90104">https://reviews.llvm.org/D90104</a>, 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.</div><div><br></div><div>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.</div><div><br></div><div>Regards,<br></div><div>Nikita<br></div></div></div>