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

[Jakob Stoklund Olesen]

On Apr 16, 2012, at 3:30 PM, Chandler Carruth <chandlerc at google.com> wrote:

> 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?

I don't know what would break, but DAGCombine already has these tricks:

$ cat small2.c 
unsigned f(unsigned x) {
  return x >> 2 << 3 >> 2 << 5;
}

With the shift transforms disabled, we get:

define i32 @f(i32 %x) nounwind uwtable readnone ssp {
entry:
  %shr = lshr i32 %x, 2
  %shl = shl i32 %shr, 3
  %shr1 = lshr exact i32 %shl, 2
  %shl2 = shl i32 %shr1, 5
  ret i32 %shl2
}

But DAGCombine goes:

	shll	$4, %edi
	andl	$-64, %edi
	movl	%edi, %eax
	ret

And you are right, we only get the bit masks when it is worthwhile.

/jakob

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120416/add24235/attachment.html>