Summary:
No support for symbols in place of the immediate yet since it requires new
relocations.
Depends on D3671
Reviewers: jkolek, zoran.jovanovic, vmedic
Reviewed By: vmedic
Differential Revision: http://reviews.llvm.org/D3689
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208858 91177308-0d34-0410-b5e6-96231b3b80d8
much more effectively when trying to constant fold a load of a constant.
Previously, we only handled bitcasts by trying to find a totally generic
byte representation of the constant and use that. Now, we look through
the bitcast to see what constant we might fold the load into, and then
try to form a constant expression cast of the found value that would be
equivalent to loading the value.
You might wonder why on earth this actually matters. Well, turns out
that the Itanium ABI causes us to create a single array for a vtable
where the first elements are virtual base offsets, followed by the
virtual function pointers. Because the array is homogenous the element
type is consistently i8* and we inttoptr the virtual base offsets into
the initial elements.
Then constructors bitcast these pointers to i64 pointers prior to
loading them. Boom, no more constant folding of virtual base offsets.
This is the first fix to LLVM to address the *insane* performance Eric
Niebler discovered with Clang on his range comprehensions[1]. There is
more to come though, this doesn't *really* fix the problem fully.
[1]: http://ericniebler.com/2014/04/27/range-comprehensions/
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208856 91177308-0d34-0410-b5e6-96231b3b80d8
if ((x & C) == 0) x |= C becomes x |= C
if ((x & C) != 0) x ^= C becomes x &= ~C
if ((x & C) == 0) x ^= C becomes x |= C
if ((x & C) != 0) x &= ~C becomes x &= ~C
if ((x & C) == 0) x &= ~C becomes nothing
Z3 Verifications code for above transform
http://rise4fun.com/Z3/Pmsh
Differential Revision: http://reviews.llvm.org/D3717
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208848 91177308-0d34-0410-b5e6-96231b3b80d8
Abstract variables should never have/use locations. In this case the
data wasn't used, so no functional change intended here, just
simplification.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208820 91177308-0d34-0410-b5e6-96231b3b80d8
Many old tests using prior schemas still had some brokenness here (both
indirect arrays and arrays with single bogus elements). Fixed those up
so they don't hit the new assertions.
Also reduced nesting in some places, etc.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208817 91177308-0d34-0410-b5e6-96231b3b80d8
This is just unneccessary - we only create abstract definitions when
we're inlining anyway, so there's no reason to delay this to see if
we're going to inline anything.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208798 91177308-0d34-0410-b5e6-96231b3b80d8
If the function has the landingpad instruction, then the
handlerdata should be emitted even if the function has
nouwnind attribute. Otherwise, following code will not
work:
void test1() noexcept {
try {
throw_exception();
} catch (...) {
log_unexpected_exception();
}
}
Since the cantunwind was incorrectly emitted and the
LSDA is not available.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208791 91177308-0d34-0410-b5e6-96231b3b80d8
For example
tzcntl %edi, %ebx
testl %edi, %edi
je .label
can be rewritten into
tzcntl %edi, %ebx
jb .label
A minor complication is that tzcnt sets CF instead of ZF when the input
is zero, we have to rewrite users of the flags from ZF to CF. Currently
we recognize patterns using lzcnt, tzcnt and popcnt.
Differential Revision: http://reviews.llvm.org/D3454
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208788 91177308-0d34-0410-b5e6-96231b3b80d8
Most importantly, it gives debug location info to the coverage callback.
This change also removes 2 cases of unnecessary setDebugLoc when IRBuilder
is created with the same debug location.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208767 91177308-0d34-0410-b5e6-96231b3b80d8
The ELF header e_flags field in the MIPS related test cases handled
incorrectly. The obj2yaml prints too many flags. I will fix that in the
next patches.
The patch reviewed by Michael Spencer and Sean Silva.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208752 91177308-0d34-0410-b5e6-96231b3b80d8
The UDF instruction is a reserved undefined instruction space. The assembler
mnemonic was introduced with ARM ARM rev C.a. The instruction is not predicated
and the immediate constant is ignored by the CPU. Add support for the three
encodings for this instruction.
The changes to the invalid instruction test is due to the fact that the invalid
instructions actually overlap with the undefined instruction. Introduction of
the new instruction results in a partial decode as an undefined sequence. Drop
the tests as they are invalid instruction patterns anyways.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208751 91177308-0d34-0410-b5e6-96231b3b80d8
This was reverted in r208642 due to regressions surrounding file changes
within lexical scopes causing inlining information to be lost.
The issue was in LexicalScopes::getOrCreateInlinedScope, where I was
previously testing "isLexicalBlock" which is false for
"DILexicalBlockFile" (a scope used to represent changes in the current
file name) and assuming it was then a function (breaking out of the
inlined scope path and reaching for the parent non-inlined scopes). By
inverting the condition and testing for "isSubprogram" the correct
behavior is attained.
(also found some weirdness in Clang, see r208742 when reducing this test
case - the resulting test case doesn't apply with the Clang fix, but
I've added a more realistic test case to inline-scopes.ll which does
reproduce the issue and demonstrate the fix)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208748 91177308-0d34-0410-b5e6-96231b3b80d8
Iterating over a DenseMaop is non-deterministic and results to unpredictable IR
output.
Based on a patch by Daniel Reynaud!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208728 91177308-0d34-0410-b5e6-96231b3b80d8
member variable and sink the initialization of crbits into the
subtarget feature reset code.
No functional change, but this refactor will be used in a future
commit.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208726 91177308-0d34-0410-b5e6-96231b3b80d8
This allows code to statically accept a Function or a GlobalVariable, but
not an alias. This is already a cleanup by itself IMHO, but the main
reason for it is that it gives a lot more confidence that the refactoring to fix
the design of GlobalAlias is correct. That will be a followup patch.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208716 91177308-0d34-0410-b5e6-96231b3b80d8
This commit was already commited as revision rL208689 and discussd in
phabricator revision D3704.
But the test file was crashing on OS X and windows.
I fixed the test file in the same way as in rL208340.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208711 91177308-0d34-0410-b5e6-96231b3b80d8
compared to 'AddrMode.BaseReg'. In the case that 'AddrMode.BaseReg' is
nullptr, 'Result' will also be nullptr, so the cast causes an assertion. We
should use dyn_cast_or_null here to check 'Result' is not null and it is an
instruction.
Bug found by Mats Petersson, and I reduced his IR to get a test case.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208705 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This required a new instruction group representing the 32-bit subset of
MIPS-3 that was available in MIPS32R2.
To limit the number of tests required, only one 32-bit and one 64-bit ISA
prior to MIPS32/MIPS64 are tested.
rdhwr has been deliberately left without an ISA annotation for now. This is
because the assembler and CodeGen disagree on when the instruction is
available. Strictly speaking, it is only available in MIPS32r2 and
MIPS64r2. However, it is emulated by a kernel trap on earlier ISA's and is
necessary for TLS so CodeGen should emit it on older ISA's too.
Depends on D3696
Reviewers: vmedic
Reviewed By: vmedic
Differential Revision: http://reviews.llvm.org/D3697
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208690 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
We are currently very close to the 32-bit limit of the current assembler
implementation. This is because there is no way to represent an instruction
that is available in, for example, Mips3 or Mips32. We have to define a
feature bit that represents this.
This patch cleans up a pair of redundant feature bits and slightly postpones the
point we will reach the limit.
Reviewers: zoran.jovanovic, jkolek, vmedic
Reviewed By: vmedic
Differential Revision: http://reviews.llvm.org/D3703
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208685 91177308-0d34-0410-b5e6-96231b3b80d8
