[LLVMdev] InstCombine adds bit masks, confuses self, others

[Chandler Carruth]

On Tue, Apr 17, 2012 at 12:23 AM, Jakob Stoklund Olesen <stoklund at 2pi.dk>wrote:

> I am not sure how best to fix this. If possible, InstCombine's
> canonicalization shouldn't hide arithmetic progressions behind bit masks.


The entire concept of cleverly converting arithmetic to bit masks seems
like the perfect domain for DAGCombine instead of InstCombine:

1) We know the architecture, so we can make intelligent decisions about
what masks are cheap or expensive.
2) We know the addressing modes so we can fold arithmetic into them
3) There are no more high-level optimizations we're trying to enable: gvn,
scev, loop opts, other deep math optimizations have all already had their
shot at the code.

Does sinking these into the DAGCombine layer help? How much does it break?

In the past, LLVM has been incredibly sensitive to canonicalization
changes, so I'm worried, but I've also seen a *ton* of code similar to what
you posted, and it simply makes no sense to me.

I wrote a pile of heroics in the addressing mode matching for x86 to
specifically work around these obnoxious representations.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120417/2d224fd3/attachment.html>