| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
|
|
|
|
| |
smaller than 2^n.
This has the obvious advantage of being commutable and is always a win on x86 because
const - x wastes a register there. On less weird architectures this may lead to
a regression because other arithmetic doesn't fuse with it anymore. I'll address that
problem in a followup.
llvm-svn: 147254
|
| |
|
|
|
|
| |
This will be used by SimplifyCfg in a later commit.
llvm-svn: 146803
|
| |
|
|
|
|
|
|
| |
"half precision" floating-point with a first-class type.
This patch adds basic IR support (but not codegen support).
llvm-svn: 146786
|
| |
|
|
|
|
| |
These can be reduced to "~cond & x" or "~cond | x"
llvm-svn: 146624
|
| |
|
|
| |
llvm-svn: 146409
|
| |
|
|
| |
llvm-svn: 145801
|
| |
|
|
|
|
| |
Add FIXMEs to places that are non-trivial to fix.
llvm-svn: 145661
|
| |
|
|
|
|
|
| |
where it appeared beneficial to pass.
More of rdar://10500969
llvm-svn: 145630
|
| |
|
|
|
|
| |
style issues and confusing comment
llvm-svn: 145618
|
| |
|
|
|
|
|
|
| |
(val != 0) == (-val != 0) so "abs(val) != 0" becomes "val != 0"
Fixes <rdar://problem/10482509>
llvm-svn: 145563
|
| |
|
|
| |
llvm-svn: 145470
|
| |
|
|
|
|
|
|
| |
(fptrunc (sqrt (fpext x))) -> (sqrtf x) transformation if -fno-builtin is
specified.
rdar://10466410
llvm-svn: 145460
|
| |
|
|
| |
llvm-svn: 145420
|
| |
|
|
|
|
| |
but I don't really want to try to write a testcase involving an invoke returning a pointer to a varargs function...
llvm-svn: 145347
|
| |
|
|
| |
llvm-svn: 145316
|
| |
|
|
|
|
|
|
| |
Suggested in code review by Eli.
That code in InstCombine looks kinda suspicious.
llvm-svn: 145013
|
| |
|
|
| |
llvm-svn: 144648
|
| |
|
|
|
|
| |
Fixes r8429
llvm-svn: 144036
|
| |
|
|
| |
llvm-svn: 143634
|
| |
|
|
|
|
| |
with another instruction. (Specifically, don't insert an arbitrary instruction before a PHI.) Fixes PR11275.
llvm-svn: 143437
|
| |
|
|
|
|
| |
expensive helper.
llvm-svn: 142672
|
| |
|
|
|
|
| |
the input and output vectors have different sizes. Patch by Xiaoyi Guo.
llvm-svn: 142671
|
| |
|
|
|
|
|
|
| |
combining of the landingpad instruction. The ObjC personality function acts
almost identically to the C++ personality function. In particular, it uses
"null" as a "catch-all" value.
llvm-svn: 142256
|
| |
|
|
|
|
|
|
|
|
|
|
| |
profile metadata at the same time. Use it to preserve metadata attached
to a branch when re-writing it in InstCombine.
Add metadata to the canonicalize_branch InstCombine test, and check that
it is tranformed correctly.
Reviewed by Nick Lewycky!
llvm-svn: 142168
|
| |
|
|
|
|
|
|
| |
Just pull the instruction name, but don't change the order of anything
else. That keeps --debug happy and non-crashing, but doesn't change
how the worklist gets built.
llvm-svn: 141210
|
| |
|
|
| |
llvm-svn: 141209
|
| |
|
|
|
|
|
|
|
|
|
|
| |
When updating the worklist for InstCombine, the Add/AddUsersToWorklist
functions may access the instruction(s) being added, for debug output for
example. If the instructions aren't yet added to the basic block, this
can result in a crash. Finish the instruction transformation before
adjusting the worklist instead.
rdar://10238555
llvm-svn: 141203
|
| |
|
|
|
|
| |
r140966.
llvm-svn: 140969
|
| |
|
|
|
|
| |
but not load instructions. Noticed by inspection.
llvm-svn: 140966
|
| |
|
|
| |
llvm-svn: 140875
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
InstCombine was incorrectly considering the conversion of the constant
zero to be unsafe.
We want to transform:
define float @bar(float %x) nounwind readnone optsize ssp {
%conv = fpext float %x to double
%cmp = fcmp olt double %conv, 0.000000e+00
%conv1 = zext i1 %cmp to i32
%conv2 = sitofp i32 %conv1 to float
ret float %conv2
}
Into:
define float @bar(float %x) nounwind readnone optsize ssp {
%cmp = fcmp olt float %x, 0.000000e+00 ; <---- This
%conv1 = zext i1 %cmp to i32
%conv2 = sitofp i32 %conv1 to float
ret float %conv2
}
rdar://10215914
llvm-svn: 140869
|
| |
|
|
| |
llvm-svn: 140865
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
catch or repeated filter clauses. Teach instcombine a bunch
of tricks for simplifying landingpad clauses. Currently the
code only recognizes the GNU C++ and Ada personality functions,
but that doesn't stop it doing a bunch of "generic" transforms
which are hopefully fine for any real-world personality function.
If these "generic" transforms turn out not to be generic, they
can always be conditioned on the personality function. Probably
someone should add the ObjC++ personality function. I didn't as
I don't know anything about it.
llvm-svn: 140852
|
| |
|
|
|
|
| |
operand ordering. Patch by Stepan Dyatkovskiy.
llvm-svn: 140803
|
| |
|
|
|
|
|
|
| |
to be uniqued, without any benefit.
If someone prefers %tmp42 to %42, run instnamer.
llvm-svn: 140634
|
| |
|
|
|
|
|
|
| |
construct is changed when it is not. (See included testcase.)
Patch by Xiaoyi Guo.
llvm-svn: 140072
|
| |
|
|
|
|
| |
Spotted by inspection.
llvm-svn: 139768
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
init.trampoline and adjust.trampoline intrinsics, into two intrinsics
like in GCC. While having one combined intrinsic is tempting, it is
not natural because typically the trampoline initialization needs to
be done in one function, and the result of adjust trampoline is needed
in a different (nested) function. To get around this llvm-gcc hacks the
nested function lowering code to insert an additional parent variable
holding the adjust.trampoline result that can be accessed from the child
function. Dragonegg doesn't have the luxury of tweaking GCC code, so it
stored the result of adjust.trampoline in the memory GCC set aside for
the trampoline itself (this is always available in the child function),
and set up some new memory (using an alloca) to hold the trampoline.
Unfortunately this breaks Go which allocates trampoline memory on the
heap and wants to use it even after the parent has exited (!). Rather
than doing even more hacks to get Go working, it seemed best to just use
two intrinsics like in GCC. Patch mostly by Sanjoy Das.
llvm-svn: 139140
|
| |
|
|
|
|
| |
landingpad and terminator).
llvm-svn: 139090
|
| |
|
|
| |
llvm-svn: 139023
|
| |
|
|
| |
llvm-svn: 138968
|
| |
|
|
|
|
| |
Duncan noticed this!
llvm-svn: 138967
|
| |
|
|
|
|
| |
which should be removed only when its invokes are.
llvm-svn: 138932
|
| |
|
|
| |
llvm-svn: 138931
|
| |
|
|
|
|
| |
The landingpad instruction can be removed only when its invokes are removed.
llvm-svn: 138930
|
| |
|
|
|
|
|
| |
Optimize chained bitcasts of the form A->B->A.
Undo r138722 and change isEliminableCastPair to allow this case.
llvm-svn: 138756
|
| |
|
|
| |
llvm-svn: 138722
|
| |
|
|
|
|
| |
getFirstNonPHI so that it will skip over the landingpad instructions as well.
llvm-svn: 138537
|
| |
|
|
|
|
| |
instruction should be marked as potentially reading and/or writing memory.
llvm-svn: 137863
|
| |
|
|
|
|
| |
check for a LandingPadInst.
llvm-svn: 137745
|