|  | Commit message (Collapse) | Author | Age | Files | Lines | 
|---|
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | good code on PR4216:
_test_bitfield:                                             ## @test_bitfield
	orl	$32962, %edi
	movl	$4294941946, %eax
	andq	%rdi, %rax
	ret
instead of:
_test_bitfield:
        movl    $4294941696, %ecx
        movl    %edi, %eax
        orl     $194, %edi
        orl     $32768, %eax
        andq    $250, %rdi
        andq    %rax, %rcx
        movq    %rdi, %rax
        orq     %rcx, %rax
        ret
Evan is looking into the remaining andq+imm -> andl optimization.
llvm-svn: 93147 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | BitsToClear case.  This allows it to promote expressions which have an
and/or/xor after the lshr, promoting cases like test2 (from PR4216) 
and test3 (random extample extracted from a spec benchmark).
clang now compiles the code in PR4216 into:
_test_bitfield:                                             ## @test_bitfield
	movl	%edi, %eax
	orl	$194, %eax
	movl	$4294902010, %ecx
	andq	%rax, %rcx
	orl	$32768, %edi
	andq	$39936, %rdi
	movq	%rdi, %rax
	orq	%rcx, %rax
	ret
instead of:
_test_bitfield:                                             ## @test_bitfield
	movl	%edi, %eax
	orl	$194, %eax
	movl	$4294902010, %ecx
	andq	%rax, %rcx
	shrl	$8, %edi
	orl	$128, %edi
	shlq	$8, %rdi
	andq	$39936, %rdi
	movq	%rdi, %rax
	orq	%rcx, %rax
	ret
which is still not great, but is progress.
llvm-svn: 93145 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| | new BitsToClear result which allows us to start promoting
expressions that end with a lshr-by-constant.  This is
conservatively correct and better than what we had before
(see testcases) but still needs to be extended further.
llvm-svn: 93144 | 
| | 
| 
| 
| | llvm-svn: 93143 | 
| | 
| 
| 
| 
| 
| | the dest of the sext.
llvm-svn: 93128 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | the zext dest type.  This allows us to handle test52/53 in cast.ll,
and allows llvm-gcc to generate much better code for PR4216 in -m64
mode:
_test_bitfield:                                             ## @test_bitfield
	orl	$32962, %edi
	movl	%edi, %eax
	andl	$-25350, %eax
	ret
This also fixes a bug handling vector extends, ensuring that the
mask produced is a vector constant, not an integer constant.
llvm-svn: 93127 | 
| | 
| 
| 
| 
| 
| | simpler profitability predicate.
llvm-svn: 93111 | 
| | 
| 
| 
| | llvm-svn: 93110 | 
| | 
| 
| 
| 
| 
| 
| 
| | elimination of a sign extend to be a win, which simplifies 
the client of CanEvaluateSExtd, and allows us to eliminate
more casts (examples taken from real code).
llvm-svn: 93109 | 
| | 
| 
| 
| 
| 
| 
| 
| | lshr+ashr instead of trunc+sext.  We want to avoid type 
conversions whenever possible, it is easier to codegen expressions
without truncates and extensions.
llvm-svn: 93107 | 
| | 
| 
| 
| | llvm-svn: 93106 | 
| | 
| 
| 
| | llvm-svn: 93105 | 
| | 
| 
| 
| 
| 
| 
| | bits known clear in the result and don't care about the # casts 
eliminated.  TD is also dead but keeping it for now.
llvm-svn: 93098 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | 1) don't try to optimize a sext or zext that is only used by a trunc, let
   the trunc get optimized first.  This avoids some pointless effort in
   some common cases since instcombine scans down a block in the first pass.
2) Change the cost model for zext elimination to consider an 'and' cheaper
   than a zext.  This allows us to do it more aggressively, and for the next
   patch to simplify the code quite a bit.
llvm-svn: 93097 | 
| | 
| 
| 
| 
| 
| | more expressions to be promoted and casts eliminated.
llvm-svn: 93096 | 
| | 
| 
| 
| | llvm-svn: 93095 | 
| | 
| 
| 
| | llvm-svn: 93093 | 
| | 
| 
| 
| | llvm-svn: 93092 | 
| | 
| 
| 
| | llvm-svn: 93091 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| | commonIntCastTransforms into the callers, eliminating a switch,
and allowing the static predicate  methods to be moved down to
live next to the corresponding function.  No functionality 
change.
llvm-svn: 93089 | 
| | 
| 
| 
| 
| 
| | base is the right expression type.  This fixes PR5981.
llvm-svn: 93045 | 
| | 
| 
| 
| | llvm-svn: 93038 | 
| | 
| 
| 
| | llvm-svn: 93026 | 
| | 
| 
| 
| | llvm-svn: 93024 | 
| | 
| 
| 
| 
| 
| | simplify it now that it is only used for truncates.
llvm-svn: 93021 | 
| | 
| 
| 
| 
| 
| | the input is already sign extended.
llvm-svn: 93019 | 
| | 
| 
| 
| 
| 
| | remove some trailing whitespace while there.
llvm-svn: 93008 | 
| | 
| 
| 
| | llvm-svn: 93007 | 
| | 
| 
| 
| | llvm-svn: 92964 | 
| | 
| 
| 
| 
| 
| 
| | that feeds into a zext, similar to the patch I did yesterday for sext.
There is a lot of room for extension beyond this patch.
llvm-svn: 92962 | 
| | 
| 
| 
| | llvm-svn: 92912 | 
| | 
| 
| 
| 
| 
| | are prepared to look through.
llvm-svn: 92898 | 
| | 
| 
| 
| | llvm-svn: 92892 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| | to an element of a vector in a static ctor) which occurs with an 
unrelated patch I'm testing.  Annoyingly, EvaluateStoreInto basically 
does exactly the same stuff as InsertElement constant folding, but it
now handles vectors, and you can't insertelement into a vector.  It
would be 'really nice' if GEP into a vector were not legal.
llvm-svn: 92889 | 
| | 
| 
| 
| 
| 
| | it work for any integer size return type.
llvm-svn: 92853 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| | phi nodes when deciding which pointers point to local memory.
I actually checked long ago how useful this is, and it isn't
very: it hardly ever fires in the testsuite, but since Chris
wants it here it is!
llvm-svn: 92836 | 
| | 
| 
| 
| | llvm-svn: 92831 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| | memcpy, memset and other intrinsics that only access their arguments
to be readnone if the intrinsic's arguments all point to local memory.
This improves the testcase in the README to readonly, but it could in
theory be made readnone, however this would involve more sophisticated
analysis that looks through the memcpy.
llvm-svn: 92829 | 
| | 
| 
| 
| | llvm-svn: 92824 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | Previously, instcombine would only promote an expression tree to
the larger type if doing so eliminated two casts.  This is because
a need to manually do the sign extend after the promoted expression
tree with two shifts.  Now, we keep track of whether the result of
the computation is going to be properly sign extended already.  If
so, we can unconditionally promote the expression, which allows us
to zap more sext's.
This implements rdar://6598839 (aka gcc pr38751)
llvm-svn: 92815 | 
| | 
| 
| 
| | llvm-svn: 92800 | 
| | 
| 
| 
| | llvm-svn: 92795 | 
| | 
| 
| 
| | llvm-svn: 92792 | 
| | 
| 
| 
| | llvm-svn: 92790 | 
| | 
| 
| 
| 
| 
| 
| | The only difference is that EvaluateInDifferentType checks to ensure
they are profitable before doing them :)
llvm-svn: 92788 | 
| | 
| 
| 
| | llvm-svn: 92775 | 
| | 
| 
| 
| | llvm-svn: 92773 | 
| | 
| 
| 
| | llvm-svn: 92771 | 
| | 
| 
| 
| 
| 
| | modernize it.
llvm-svn: 92770 | 
| | 
| 
| 
| | llvm-svn: 92768 |