[llvm-dev] Benchmark GlobalsModRef in non-LTO pass pipeline

James Molloy via llvm-dev llvm-dev at lists.llvm.org
Mon Aug 10 08:06:11 PDT 2015


To amend what I said earlier, after a lot more investigation it turns out
the problem is that a bunch of optimization passes don't preserve
AliasAnalysis. If I add AU.setPreserved<AliasAnalysis> to a bunch of them,
passes such as LICM end up seeing GMR in its alias analysis chain. That's
when I start to see improvements.


On Mon, 10 Aug 2015 at 10:06 James Molloy <james at jamesmolloy.co.uk> wrote:

> Hi Chandler,
> Sorry it took so long for me to get to this. I'm very keen to get GMR
> enabled in the non-LTO pipeline. I see nontrivial perf improvements in a
> bunch of workloads I care about with it enabled, but with a patch applied
> to run GMR again after the LoopPasses but before the FunctionPasses.
> I've found this is critical - LICM needs GMR available, and the
> passmanager kills it by the time the early LICM is run.
> I'd be really keen to get this enabled by default, with that extra run
> added. I assume the need for this extra run will evaporate with the new
> pass manager?
> Cheers,
> James
> On Thu, 6 Aug 2015 at 03:45 Chandler Carruth <chandlerc at gmail.com> wrote:
>> Greetings folks!
>> I would like to enable globalsmodref-aa in the non-LTO pass pipeline so
>> that it gets tested more and there are fewer differences between the two.
>> For all of my benchmarks, this is performance neutral, but I'd appreciate
>> others benchmarking this combination to see if they see any benefits or
>> regressions.
>> You can demo this mode easily: -mllvm -enable-non-lto-gmr
>> Please let me know!
>> -Chandler
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org         http://llvm.cs.uiuc.edu
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150810/d120c727/attachment.html>

More information about the llvm-dev mailing list