[PATCH] Add support for combining GEPs across PHI nodes

[Chandler Carruth]

Really cool.

Some comments on the patch itself:

+    unsigned DI = ~0x0U;

Maybe use an int and '-1'? Seems a bit simpler to read.

+    if (PtrOp->hasNUses(0)) {

->use_empty()

+      for (auto &I : PN->operands())
+        if (I->hasOneUse()) {
+          // The one use is the node we are about to delete, so it is safe
to
+          // this GEP.
+          dyn_cast<Instruction>(PtrOp)->eraseFromParent();
+        }
+      dyn_cast<Instruction>(PtrOp)->eraseFromParent();
+    }

Why bother with this? I guess it doesn't hurt, but I thought instcombine
would handle this kind of thing for you.

If you want to do it: RecursivelyDeleteTriviallyDeadInstructions

Feel free to submit whenever, these are all really minor comments.

PS: Any chance I can convince you to use phabricator? ;]


On Fri, May 16, 2014 at 4:21 PM, Louis Gerbarg <lgg at apple.com> wrote:

> The attached patch modifies InstCombine’s GEP code to merge GEPs that are
> split apart by PHIs. The existing code already generally merges GEP chains
> as aggressively as it can unless intermediary parts of the chain have
> additional uses that cannot be combined, so this patch makes the GEP chain
> folding more consistent overall. It also allows the target independent
> optimizer to hand more expressive GEPs to the backends, which can then use
> more complex addressing modes when appropriate. More details of the actual
> mechanics are in the patch.
>
> A concrete example of why want to do this is:
>
> unsigned testu(llvm::DenseMap<unsigned, unsigned> &dm, unsigned key) {
>     return dm.lookup(key);
> }
>
> The generated code includes the following assembly:
>
> LBB0_6:
>         leaq    (%r8,%rdi,8), %rax
>         movl    4(%rax), %eax
>
> which can be merged into a single instruction by the x86 backend provided
> the GEPs are merged across a PHI.
>
> LBB0_6:                                 ## %if.then.i
>         movl    4(%r8,%rdi,8), %eax
>
> Louis
>
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140516/3f8a862d/attachment.html>