<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><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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">hfinkel added a comment.<br>
<span class=""><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>