<div dir="ltr">The funny thing is, we actually *did* have most of this discussion. ;] It was Hal's second comment on my big AA infrastructure patch which you can find here: <a href="http://reviews.llvm.org/D12080" target="_blank">http://reviews.llvm.org/D12080</a><div><br></div><div>The summary is that this is obviously an important use case long-term. The infrastructure was designed to make it possible to handle this, the only actual lack of flexibility is in the legacy pass manager wrapper, and only there because at the time there wasn't anything in-tree that needed the flexibility. The new pass manager has this essentially baked-in.</div><div><br></div><div>The reason I didn't just bake this into the legacy pass manager is... well... the legacy pass manager makes this pretty ridiculously annoying to implement. There is no point at which you can really "parameterize" the analysis passes in the legacy pass manager. So the least bad idea I've come up with is... incredibly ugly:</div><div><br></div><div>- Create an ImmutablePass which is a TargetAAWrapperPass or some such horror, which can be constructed from a callable that can be passed an AAResults object and will register with it any target-specific AAResult object. And it exposes this callable (or this functionality) from its API.</div><div><br></div><div>- Teach the AAResultsWrapperPass to use this horror if it is available, but ignore it otherwise.</div><div><br></div><div>- Add the TargetAAWrapperPass outside of the PassManagerBuilder similarly to how we add the TargetTransformInfoWrapperPass.</div><div><br></div><div>Anyone else have less horrible ideas about how to thread these things together?</div><div><br></div><div>However, all this said, I'm not sure whether what we really want is to make target-specific AAs easy, or to come up with an interface for an address space aware AA to query the target for its interpretation of address spaces.</div><div><br></div><div>-Chandler</div><div><br></div><div><br></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Mar 15, 2016 at 7:23 PM Hal Finkel <<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="font-family:arial,helvetica,sans-serif;font-size:10pt;color:#000000"><br><hr><blockquote style="border-left:2px solid rgb(16,16,255);margin-left:5px;padding-left:5px;color:rgb(0,0,0);font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt"><b>From: </b>"Daniel Berlin" <<a href="mailto:dberlin@dberlin.org" target="_blank">dberlin@dberlin.org</a>><br><b>To: </b><a href="mailto:reviews%2BD12414%2Bpublic%2Bcf5673a649e54709@reviews.llvm.org" target="_blank">reviews+D12414+public+cf5673a649e54709@reviews.llvm.org</a><br><b>Cc: </b>"Jingyue Wu" <<a href="mailto:jingyue@google.com" target="_blank">jingyue@google.com</a>>, <a href="mailto:wengxt@gmail.com" target="_blank">wengxt@gmail.com</a>, "Chandler Carruth" <<a href="mailto:chandlerc@gmail.com" target="_blank">chandlerc@gmail.com</a>>, "Justin Holewinski" <<a href="mailto:jholewinski@nvidia.com" target="_blank">jholewinski@nvidia.com</a>>, "Eli Bendersky" <<a href="mailto:eliben@google.com" target="_blank">eliben@google.com</a>>, "Hal Finkel" <<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>>, "Bjarke Roune" <<a href="mailto:broune@google.com" target="_blank">broune@google.com</a>>, "Mark Heffernan" <<a href="mailto:meheff@google.com" target="_blank">meheff@google.com</a>>, "llvm-commits" <<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a>><br><b>Sent: </b>Tuesday, March 15, 2016 1:03:35 PM<br><b>Subject: </b>Re: [PATCH] D12414: [NVPTX] add an NVPTX-specific alias analysis</blockquote></div></div><div><div style="font-family:arial,helvetica,sans-serif;font-size:10pt;color:#000000"><blockquote style="border-left:2px solid rgb(16,16,255);margin-left:5px;padding-left:5px;color:rgb(0,0,0);font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt"><br><br><div dir="ltr">+1.<br><div>If we need this, we should make it work ;)<br><br></div><div>I'm not sure anyone sat down and said "it would be really bad to let targets have their own AA", and make such a decision</div><div>(if they did, they didn't discuss it on llvm-dev)</div><div><br></div></div></blockquote></div></div><div><div style="font-family:arial,helvetica,sans-serif;font-size:10pt;color:#000000"><blockquote style="border-left:2px solid rgb(16,16,255);margin-left:5px;padding-left:5px;color:rgb(0,0,0);font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt"></blockquote><br>I'm pretty sure I specifically requested that the infrastructure design not preclude this from working. We certainly don't want targets working around general AA deficiencies with target-specific passes, but for dealing with target-specific intrinsics and address spaces (etc.) I think it makes a lot of sense.<br><br> -Hal</div></div><div><div style="font-family:arial,helvetica,sans-serif;font-size:10pt;color:#000000"><br><br><blockquote style="border-left:2px solid rgb(16,16,255);margin-left:5px;padding-left:5px;color:rgb(0,0,0);font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt"><div dir="ltr"><div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 15, 2016 at 10:57 AM, Hal Finkel <span dir="ltr"><<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">hfinkel added a comment.<br>
<span><br>
In <a href="http://reviews.llvm.org/D12414#375657" rel="noreferrer" target="_blank">http://reviews.llvm.org/D12414#375657</a>, @jingyue wrote:<br>
<br>
> It doesn't work with the new alias analysis infrastructure.<br>
><br>
> I didn't manage to find a way to run it with `opt`. The new AliasAnalysis needs to know and populate all potential alias analyses in a target-independent phase. However, NVPTXAliasAnalysis is target-dependent and not even visible to AliasAnalysis (e.g. compiling LLVM with NVPTX disabled).<br>
<br>
<br>
</span>Do you have an alternative plan?<br>
<br>
It seems like we could add a feature in the new AA to query a target-provided analysis.<br>
<br>
<br>
<a href="http://reviews.llvm.org/D12414" rel="noreferrer" target="_blank">http://reviews.llvm.org/D12414</a><br>
<br>
<br>
<br>
</blockquote></div><br></div>
</blockquote><br><br><br></div></div><div><div style="font-family:arial,helvetica,sans-serif;font-size:10pt;color:#000000">-- <br><div><span name="x"></span>Hal Finkel<br>Assistant Computational Scientist<br>Leadership Computing Facility<br>Argonne National Laboratory<span name="x"></span><br></div></div></div></blockquote></div></div>