(x > y) ? x : y
=>
(x >= y) ? x : y
So for something like
(x - y) > 0 : (x - y) ? 0
It will be
(x - y) >= 0 : (x - y) ? 0
This makes is possible to test sign-bit and eliminate a comparison against
zero. e.g.
subl %esi, %edi
testl %edi, %edi
movl $0, %eax
cmovgl %edi, %eax
=>
xorl %eax, %eax
subl %esi, $edi
cmovsl %eax, %edi
rdar://10633221
llvm-svn: 147512
Before we'd get:
$ clang t.c
fatal error: error in backend: Invalid operand for inline asm constraint 'i'!
Now we get:
$ clang t.c
t.c:16:5: error: invalid operand for inline asm constraint 'i'!
"movq (%4), %%mm0\n"
^
Which at least gets us the inline asm that is the problem.
llvm-svn: 147502
This patch caused a miscompilation of oggenc because a frame pointer was
suddenly needed halfway through register allocation.
<rdar://problem/10625436>
llvm-svn: 147487
If anybody has strong feelings about 'default: assert(0 && "blah")' vs
'default: llvm_unreachable("blah")', feel free to regularize the instances of
each in this file.
llvm-svn: 147459
The failure seen on win32, when i64 type is illegal.
It happens on stage of conversion VECTOR_SHUFFLE to BUILD_VECTOR.
The failure message is:
llc: SelectionDAG.cpp:784: void VerifyNodeCommon(llvm::SDNode*): Assertion `(I->getValueType() == EltVT || (EltVT.isInteger() && I->getValueType().isInteger() && EltVT.bitsLE(I->getValueType()))) && "Wrong operand type!"' failed.
I added a special test that checks vector shuffle on win32.
llvm-svn: 147445
is testing the bitcode reader's functionality, not VMCore's. Add the
what is a hope sufficient build system mojo to build and run a new
unittest.
Also clean up some of the test's naming. The goal for the file should be
to unittest the Bitcode Reader, and this is just one particular test
among potentially many in the future. Also, reverse my position and
relegate the PR# to a comment, but stash the comment on the same line as
the test name so it doesn't get lost. This makes the code more
self-documenting hopefully w/o losing track of the PR number.
llvm-svn: 147431
build. This didn't show up in the CMake build because the CMake build
for the unittests is rather poorly factored.
This probably isn't the correct fix. This should be a bitcode reader
unittest not a VMCore unittest. I'll move it and clean various parts of
the unittest up in a follow-up patch, but I wanted to unbreak the bots.
llvm-svn: 147427
The failure seen on win32, when i64 type is illegal.
It happens on stage of conversion VECTOR_SHUFFLE to BUILD_VECTOR.
The failure message is:
llc: SelectionDAG.cpp:784: void VerifyNodeCommon(llvm::SDNode*): Assertion `(I->getValueType() == EltVT || (EltVT.isInteger() && I->getValueType().isInteger() && EltVT.bitsLE(I->getValueType()))) && "Wrong operand type!"' failed.
I added a special test that checks vector shuffle on win32.
llvm-svn: 147399
See PR11652. Trying to add this assert to
setSubclassData() itself actually prevented
the miscompile entirely, so it has to be here.
This makes the source of the bug more obvious
than the other asserts triggering later on did.
llvm-svn: 147390
Implement encoder methods getJumpTargetOpValue and getBranchTargetOpValue
for jmptarget and brtarget Mips tablegen operand types in the code emitter
for old-style JIT. Rename the pc relative relocation for branches - new
name is Mips::reloc_mips_pc16.
Patch by Sasa Stankovic
llvm-svn: 147382
Evan Cheng