Currently the large code model for MachO uses the GOT to make function calls.
Emit the required adrp and ldr instructions to load the address from the GOT.
Related to <rdar://problem/17733076>.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214381 91177308-0d34-0410-b5e6-96231b3b80d8
Instead allow the variable to be declared, but don't attach an initializer. This allows more than a single error to be emitted before we exit.
Test case to follow soon in another patch.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214375 91177308-0d34-0410-b5e6-96231b3b80d8
This is currently for assigning from one bit init to another. It can easily be extended to other types.
Test to follow soon in another patch.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214374 91177308-0d34-0410-b5e6-96231b3b80d8
Since initializers of GlobalValues are being assigned IDs before
GlobalValues themselves, explicitly exclude GlobalValues from the
constant pool. Added targeted test in `test/Bitcode/use-list-order.ll`
and added two more RUN lines in `test/Assembly`.
This is part of PR5680.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214368 91177308-0d34-0410-b5e6-96231b3b80d8
This fixes a mistake where I accidentially dropped the upper 32bit of a
64bit pointer during FastISel lowering of the patchpoint intrinsic.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214367 91177308-0d34-0410-b5e6-96231b3b80d8
UNDEF arguments are not ment to be touched - especially for the webkit_js
calling convention. This fix reproduces the already existing behavior of
SelectionDAG in FastISel.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214366 91177308-0d34-0410-b5e6-96231b3b80d8
Add RUN line for `verify-uselistorder` to every test in `test/Assembly`,
unless it's a negative check (assembler rejects it) or verification
fails.
There are three files that verification fails on (so I've left out the
RUN lines):
- 2002-08-22-DominanceProblem.ll
- ConstantExprFold.ll
- ConstantExprFoldCast.ll
This is part of PR5680.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214365 91177308-0d34-0410-b5e6-96231b3b80d8
In some places we've been using different suffixes for the different
file formats involved in instrprof, but in others we've just
ambiguously used .profdata. Update the test files to indicate the
types of file more obviously.
No functional change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214357 91177308-0d34-0410-b5e6-96231b3b80d8
Before this patch we had
@a = weak global ...
but
@b = alias weak ...
The patch changes aliases to look more like global variables.
Looking at some really old code suggests that the reason was that the old
bison based parser had a reduction for alias linkages and another one for
global variable linkages. Putting the alias first avoided the reduce/reduce
conflict.
The days of the old .ll parser are long gone. The new one parses just "linkage"
and a later check is responsible for deciding if a linkage is valid in a
given context.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214355 91177308-0d34-0410-b5e6-96231b3b80d8
This works towards making the Intel syntax asm matcher use a completely
different disambiguation strategy.
No functional change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214352 91177308-0d34-0410-b5e6-96231b3b80d8
This improves the code generation for the XALU intrinsics when the
condition is feeding a select instruction.
This also updates and enables the XALU unit tests for FastISel.
This fixes <rdar://problem/17831117>.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214350 91177308-0d34-0410-b5e6-96231b3b80d8
This improves the code generation for the XALU intrinsics when the
condition is feeding a branch instruction.
This is related to <rdar://problem/17831117>.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214349 91177308-0d34-0410-b5e6-96231b3b80d8
This commit adds support for the {s|u}{add|sub|mul}.with.overflow intrinsics.
The unit tests for FastISel will be enabled in a later commit, once there is
also branch and select folding support.
This is related to <rdar://problem/17831117>.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214348 91177308-0d34-0410-b5e6-96231b3b80d8
Move the helper function isCommutativeIntrinsic into the FastISel base class,
so it can be used by more than just one backend.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214347 91177308-0d34-0410-b5e6-96231b3b80d8
Currently the shift-immediate versions are not supported by tblgen and
hopefully this can be later removed, once the required support has been
added to tblgen.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214345 91177308-0d34-0410-b5e6-96231b3b80d8
While we can already transform A | (A ^ B) into A | B, things get bad
once we have (A ^ B) | (A ^ B ^ Cst) because reassociation will morph
this into (A ^ B) | ((A ^ Cst) ^ B). Our existing patterns fail once
this happens.
To fix this, we add a new pattern which looks through the tree of xor
binary operators to see that, in fact, there exists a redundant xor
operation.
What follows bellow is a correctness proof of the transform using CVC3.
$ cat t.cvc
A, B, C : BITVECTOR(64);
QUERY BVXOR(A, B) | BVXOR(BVXOR(B, C), A) = BVXOR(A, B) | C;
QUERY BVXOR(BVXOR(A, C), B) | BVXOR(A, B) = BVXOR(A, B) | C;
QUERY BVXOR(A, B) & BVXOR(BVXOR(B, C), A) = BVXOR(A, B) & ~C;
QUERY BVXOR(BVXOR(A, C), B) & BVXOR(A, B) = BVXOR(A, B) & ~C;
$ cvc3 < t.cvc
Valid.
Valid.
Valid.
Valid.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214342 91177308-0d34-0410-b5e6-96231b3b80d8
The lifetime intrinsics need some work in order to make it clear which
optimizations are or are not valid.
For now dropping this optimization avoids a miscompilation.
Patch by Björn Steinbrink.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214336 91177308-0d34-0410-b5e6-96231b3b80d8
This patch adds an explicit triple to the test case introduced by r214322. This
should fix build failueres that are occuring on bots that are cross building.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214330 91177308-0d34-0410-b5e6-96231b3b80d8
DAGCombine may choose to rewrite graphs where two loads feed a select into
graphs where a select of two addresses feed a load. While it sanity checks the
loads to make sure they are broadly equivalent it currently just uses the
alignment restriction of the left node. In cases where the right node has
stronger alignment requiresment this may lead to bad codegen, such as generating
an aligned load where an unaligned load is required. This patch makes the
combine generate a load with an alignment that is the same as whichever is more
restrictive of the two alignments.
Tests included.
rdar://17762530
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214322 91177308-0d34-0410-b5e6-96231b3b80d8
When predicting use-list order, we visit functions in reverse order
followed by `GlobalValue`s and write out use-lists at the first
opportunity. In the reader, this will translate to *after* the last use
has been added.
For this to work, we actually need to descend into `GlobalValue`s.
Added a targeted test in `use-list-order.ll` and `RUN` lines to the
newly passing tests in `test/Bitcode`.
There are two remaining failures in `test/Bitcode`:
- blockaddress.ll: I haven't thought through how to model the way
block addresses change the order of use-lists (or how to work around
it).
- metadata-2.ll: There's an old-style `@llvm.used` global array here
that I suspect the .ll parser isn't upgrading properly. When it
round-trips through bitcode, the .bc reader *does* upgrade it, so
the extra variable (`i8* null`) has an extra use, and the shuffle
vector doesn't match.
I think the fix is to upgrade old-style global arrays (or reject
them?) in the .ll parser.
This is part of PR5680.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214321 91177308-0d34-0410-b5e6-96231b3b80d8
Turns out `parseBitcodeFile()` does *not* take ownership of the buffer.
This was already clear in the header docs, but I obviously didn't read
them (having noticed that it gets stored in a `unique_ptr<>`).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214313 91177308-0d34-0410-b5e6-96231b3b80d8
According to VectorType::isValidElementType, any integer, floating point
or pointer type is a valid vector element type.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214302 91177308-0d34-0410-b5e6-96231b3b80d8
the jump instruction table pass. First, the verifier is already built
into all the tools. The test case is adapted to just run llvm-as
demonstrating that we still catch the broken module. Second, the
verifier is *extremely* slow. This was responsible for very significant
compile time regressions.
If you have deployed a Clang binary anywhere from r210280 to this
commit, you really want to re-deploy.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214287 91177308-0d34-0410-b5e6-96231b3b80d8
We now (1) correctly decode the branch immediate, (2) modify the immediate to
corretly treat it as PC-rel, and (3) properly populate the stub entry.
Previously we had been doing each of these wrong.
<rdar://problem/17750739>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214285 91177308-0d34-0410-b5e6-96231b3b80d8
