Using DenseMap iterators isn't free as they have to check for empty
buckets. Dominator queries are common so this gives a minor speedup.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147544 91177308-0d34-0410-b5e6-96231b3b80d8
Get back getHostTriple.
For JIT compilation, use the host triple instead of the default
target: this fixes some JIT testcases that used to fail when the
compiler has been configured as a cross compiler.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147542 91177308-0d34-0410-b5e6-96231b3b80d8
versions derive from them.
- JALR64 is not needed since N64 does not emit jal.
- Add template parameter to BranchLink that sets the rt field.
- Fix the set of temporary registers for O32 and N64.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147518 91177308-0d34-0410-b5e6-96231b3b80d8
(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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147512 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147502 91177308-0d34-0410-b5e6-96231b3b80d8
This patch caused a miscompilation of oggenc because a frame pointer was
suddenly needed halfway through register allocation.
<rdar://problem/10625436>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147487 91177308-0d34-0410-b5e6-96231b3b80d8
This can only happen if the set of reserved registers changes during
register allocation.
<rdar://problem/10625436>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147486 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147459 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147445 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147431 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147427 91177308-0d34-0410-b5e6-96231b3b80d8
