Heikki Kultala
2014-Jun-06 13:11 UTC
[LLVMdev] how to turn off conversion of add's into or's (in address calculations)
It seems some optimization pass converts some address computation add's into or's when it knows it's allowed due correct alignment. How do I turn this off keep the address calculations as adds?
Jingyue Wu
2014-Jun-06 16:38 UTC
[LLVMdev] how to turn off conversion of add's into or's (in address calculations)
HI Helkki, I guess instcombine does that. See InstCombineAddSub.cpp:1107. The optimization there is more general than converting address computation adds. If A and B don't have common bits, instcombine converts A + B to A | B. I am not aware of any configuration to turn this particular optimization off. If you just want to experiment, you can always change the code. Or you can improve your analysis/optimization to treat such OR as ADD. Ignore if you already know this: you can run "opt -O3 -print-after-all" to figure out which optimization pass does a certain thing. Jingyue On Fri, Jun 6, 2014 at 6:11 AM, Heikki Kultala <hkultala at cs.tut.fi> wrote:> It seems some optimization pass converts some address computation add's > into or's when it knows it's allowed due correct alignment. > > How do I turn this off keep the address calculations as adds? > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140606/276f4de9/attachment.html>
Matt Arsenault
2014-Jun-06 17:55 UTC
[LLVMdev] how to turn off conversion of add's into or's (in address calculations)
On 06/06/2014 09:38 AM, Jingyue Wu wrote:> HI Helkki, > > I guess instcombine does that. See InstCombineAddSub.cpp:1107. The > optimization there is more general than converting address computation > adds. If A and B don't have common bits, instcombine converts A + B to > A | B. I am not aware of any configuration to turn this particular > optimization off. If you just want to experiment, you can always > change the code. Or you can improve your analysis/optimization to > treat such OR as ADD. > > Ignore if you already know this: you can run "opt -O3 > -print-after-all" to figure out which optimization pass does a certain > thing. > > JingyueAdd the IR level, most / nearly all address calculations are hidden in GEPs. They are only really exposed later in SelectionDAG, so DAGCombiner is probably doing this> > > On Fri, Jun 6, 2014 at 6:11 AM, Heikki Kultala <hkultala at cs.tut.fi > <mailto:hkultala at cs.tut.fi>> wrote: > > It seems some optimization pass converts some address computation > add's into or's when it knows it's allowed due correct alignment. > > How do I turn this off keep the address calculations as adds? > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu> > http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140606/ef6e6d7f/attachment.html>
Reasonably Related Threads
- [LLVMdev] Question Regarding Sign-Overflow
- [LLVMdev] Loads/Stores and MachineMemOperand
- [LLVMdev] why dummy asserting base/interface class virtual methods instead of pure virtual methods?
- [LLVMdev] ANNOUNCEMENT: Removing list prefix
- [LLVMdev] Register allocation marking spills (Re: NumLoads/NumStores for linearscan?)