[llvm-commits] [llvm] r155468 - in /llvm/trunk: lib/Transforms/InstCombine/InstCombineCalls.cpp test/Transforms/InstCombine/2012-04-23-Neon-Intrinsics.ll

[Evan Cheng]

On Apr 25, 2012, at 7:37 PM, Chandler Carruth <chandlerc at google.com> wrote:

> On Wed, Apr 25, 2012 at 7:07 PM, Lang Hames <lhames at gmail.com> wrote:
> Hi Bob, Evan, 
>> I vaguely remember this. Do you remember why the multiply isn't moved together with the sext / zext?
> 
> The change was svn 128502.  The commit message doesn't have many details.  It references rdar://8832507 and rdar://9203134.  I took a quick look at 8832507, where I commented that the zext/sext was getting moved by LICM.  Presumably only one of the operands was loop-invariant, so the multiply would remain in the loop.
> 
> That makes sense. Thanks for the pointers to the commits/radars too.
> 
> I talked this over with Dan Gohman this morning and we came to the conclusion that the best way of handling this is probably to add a specialized simplify for widening mul intrinsics. It should only simplify when both operands are constant (result is constant), or either constant is zero or one (result is a sext/zext). This was one of Chandler's suggested solutions too. I'll work up a patch soonish.
> 
> While I like this solution, and particularly for widening multiplies I can see reasons to specifically prefer it, I'd like to point out one alternative to the generic problem this thread has touched on: an intrinsic that expands to multiple IR constructs which we would like to match back to exactly one instruction.
> 
> I understand the difficulty of looking across BB edges and other CFG elements, seeing through CSE and other foldings which can impact this. However, we have great tools to do all of these things, especially in the IR. The whole point of lowering to generic IR constructs is to get access to these tools.
> 
> My idea for how to handle these patterns is to have target-specific ISD nodes to represent their special semantics, and to use target-specific combines to reach across CFG and other constructs to form these ISD nodes even after optimizations. At that layer we can also avoid forming the nodes when the optimizations that have perturbed the target-independent code have actually made sufficiently significant optimizations to be superior in code quality to the instruction the intrinsic would naively have lowered to.
> 

I am not sure how this would work. Currently dag combine operates on a BB at a time. Or are you thinking about the selection dag builder time optimization that we added to deal specific with sext / zext. That's not a general solution though. One day we will implement whole function isel, and this approach should work well then. 


> We already do exactly these types of transformations to represent things like x86 addressing modes, and other complex operations where the original code was written with very specific intent as to final assembly produced, so I think that this is feasible to do (if not easy).
> 
> Certainly, there is a question of whether it is worth while in each case, etc etc. I don't see the specific intrinsics in question as necessarily important to handle in this manner. I just think this pattern is an important one to consider using in the future as it keeps the IR simple and canonical, while providing more power than simple pattern matching logic to select the final instruction.

It also depends on what kind the programs do you optimize for. Some expert programmers would take you that they expect strict one to one translation from intrinsics to instructions since compiler will never match hand crafted assembly.

Evan

> _______________________________________________
> 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/20120425/48826c7a/attachment.html>