With the forthcoming codeview::StringTable which a pdb::StringTable
would hold an instance of as one member, this ambiguity becomes
confusing. Rename to PDBStringTable to avoid this.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301948 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit c08155afc5d3230792da2ad30a046a8617735a73.
This is causing undefined symbol errors with some of the constants.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301944 91177308-0d34-0410-b5e6-96231b3b80d8
If all jobs complete successfully, use pool.close() instead of
pool.terminate() before waiting for the workers. Zach Turner reported
that he was getting "access denied" exceptions from pool.terminate().
Make the workers abort immediately without printing to stderr when they
are interrupted.
Finally, catch exceptions when attempting to remove our temporary
testing directory. On abnormal exit, there can often be open handles
that haven't been cleaned up yet.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301941 91177308-0d34-0410-b5e6-96231b3b80d8
TLSDESC_ADD_LO12 relocations
Rearrange ordering in AArch64.def to follow relocation encoding
Fix name:
R_AARCH64_P32_LD64_GOT_LO12_NC => R_AARCH64_P32_LD32_GOT_LO12_NC
Add support for several "TLS", "TLSGD", and "TLSLD" relocations for
ILP32
Fix return values from isNonILP32reloc
Add implementations for
R_AARCH64_ADR_PREL_PG_HI21_NC, R_AARCH64_P32_LD32_GOT_LO12_NC,
R_AARCH64_P32_TLSIE_LD32_GOTTPREL_LO12_NC,
R_AARCH64_P32_TLSDESC_LD32_LO12, R_AARCH64_LD64_GOT_LO12_NC,
*TLSLD_LDST128_DTPREL_LO12, *TLSLD_LDST128_DTPREL_LO12_NC,
*TLSLE_LDST128_TPREL_LO12, *TLSLE_LDST128_TPREL_LO12_NC
Modify error messages to give name of equivalent relocation in the
ABI not being used, along with better checking for non-existent
requested relocations.
Added assembler support for "pg_hi21_nc"
Relocation definitions added without implementations:
R_AARCH64_P32_TLSDESC_ADR_PREL21, R_AARCH64_P32_TLSGD_ADR_PREL21,
R_AARCH64_P32_TLSGD_ADD_LO12_NC, R_AARCH64_P32_TLSLD_ADR_PREL21,
R_AARCH64_P32_TLSLD_ADR_PAGE21, R_AARCH64_P32_TLSLD_ADD_LO12_NC,
R_AARCH64_P32_TLSLD_LD_PREL19, R_AARCH64_P32_TLSDESC_LD_PREL19,
R_AARCH64_P32_TLSGD_ADR_PAGE21, R_AARCH64_P32_TLS_DTPREL,
R_AARCH64_P32_TLS_DTPMOD, R_AARCH64_P32_TLS_TPREL,
R_AARCH64_P32_TLSDESC
Fix encoding:
R_AARCH64_P32_TLSDESC_ADR_PAGE21
Reviewers: Peter Smith
Patch by: Joel Jones (jjones@cavium.com)
Differential Revision: https://reviews.llvm.org/D32072
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301939 91177308-0d34-0410-b5e6-96231b3b80d8
Avoid analyzing functions multiple times. This allows
asserting that each function is only analyzed once.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301938 91177308-0d34-0410-b5e6-96231b3b80d8
Previously we wrote line information and file checksum
information, but we did not write information about inlinee
lines and functions. This patch adds support for that.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301936 91177308-0d34-0410-b5e6-96231b3b80d8
This was originally checked in here:
https://reviews.llvm.org/rL301923
And reverted here:
https://reviews.llvm.org/rL301924
Because there's a clang test that would fail after this. I fixed/removed the
offending CHECK lines in:
https://reviews.llvm.org/rL301928
So let's try this again. Original commit message:
This is the fold that causes the infinite loop in BoringSSL
(https://github.com/google/boringssl/blob/master/crypto/cipher/e_rc2.c)
when we fix instcombine demanded bits to prefer 'not' ops as in https://reviews.llvm.org/D32255.
There are 2 or 3 problems with dyn_castNotVal, and I don't think we can
reinstate https://reviews.llvm.org/D32255 until dyn_castNotVal is completely eliminated.
1. As shown here, it transforms 'not' into random xor. This transform is harmful to SCEV and codegen because 'not' can often be folded while random xor cannot.
2. It does not transform vector constants. This is actually a good thing, but if you don't believe the above argument, then we shouldn't have excluded vectors.
3. It tries to avoid transforming not(not(X)). That's nice, but it doesn't match the greedy nature of instcombine. If we DeMorganize a pattern that has an extra 'not' in it: ~(~(~X) & Y) --> (~X | ~Y)
That's just another case of DeMorgan, so we should trust that we'll fold that pattern too: (~X | ~ Y) --> ~(X & Y)
Differential Revision: https://reviews.llvm.org/D32665
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301929 91177308-0d34-0410-b5e6-96231b3b80d8
This is the fold that causes the infinite loop in BoringSSL
(https://github.com/google/boringssl/blob/master/crypto/cipher/e_rc2.c)
when we fix instcombine demanded bits to prefer 'not' ops as in D32255.
There are 2 or 3 problems with dyn_castNotVal, and I don't think we can
reinstate D32255 until dyn_castNotVal is completely eliminated.
1. As shown here, it transforms 'not' into random xor. This transform is
harmful to SCEV and codegen because 'not' can often be folded while
random xor cannot.
2. It does not transform vector constants. This is actually a good thing,
but if you don't believe the above argument, then we shouldn't have
excluded vectors.
3. It tries to avoid transforming not(not(X)). That's nice, but it doesn't
match the greedy nature of instcombine. If we DeMorganize a pattern
that has an extra 'not' in it:
~(~(~X) & Y) --> (~X | ~Y)
That's just another case of DeMorgan, so we should trust that we'll fold
that pattern too:
(~X | ~ Y) --> ~(X & Y)
Differential Revision: https://reviews.llvm.org/D32665
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301923 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: This is a common pattern that arise when legalizing large integers operations. Only do it when Y + 1 cannot overflow as this would change the carry behavior of uaddo .
Reviewers: jyknight, nemanjai, mkuper, spatel, RKSimon, zvi, bkramer
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D32687
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301922 91177308-0d34-0410-b5e6-96231b3b80d8
This is motivated by https://reviews.llvm.org/D32488 where I am trying
to add printing of the section type for incompatible sections to LLD
error messages. This patch allows us to use the same code in
llvm-readobj and LLD instead of duplicating the function inside LLD.
Patch by Alexander Richardson!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301921 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: Common pattern when legalizing large integers operations. Similar to D32687, when the carry isn't used.
Reviewers: jyknight, nemanjai, mkuper, spatel, RKSimon, zvi, bkramer
Differential Revision: https://reviews.llvm.org/D32738
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301919 91177308-0d34-0410-b5e6-96231b3b80d8
PR31088 demonstrated that we were assuming that only integers require promotion from <1 x iX> types, when in fact float types may require it as well - in this case half floats.
This patch adds support for extension/truncation for both integer and float types.
Differential Revision: https://reviews.llvm.org/D32391
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301910 91177308-0d34-0410-b5e6-96231b3b80d8
The existing code only looks at half of the tree when matching bswap + rol patterns ending in an OR tree (as opposed to a cascade).
Patch originally introduced by Jim Lewis.
Submitted on the behalf of Dinar Temirbulatov.
Differential Revision: https://reviews.llvm.org/D32039
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301907 91177308-0d34-0410-b5e6-96231b3b80d8
Emit and use the TableGen instruction selector for ARM. At the moment,
this allows us to remove the hand-written code for selecting G_SDIV and
G_UDIV.
Future commits will focus on increasing the code coverage for it and
removing more dead code from the current instruction selector.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301905 91177308-0d34-0410-b5e6-96231b3b80d8
A recent commit I made made it so that we only did this for signal or
interrupt handlers. This broke normal functions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301893 91177308-0d34-0410-b5e6-96231b3b80d8
Fixes PR30730.
This is a re-commit of a pulled commit. The commit was pulled because some
software projects contained uses of Altivec vectors that violated alignment
requirements. Known issues have now been fixed.
Committing on behalf of Lei Huang.
Differential Revision: https://reviews.llvm.org/D26861
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301892 91177308-0d34-0410-b5e6-96231b3b80d8
r288279 mistakenly added it to all arches, but it's only available
from v8.1 onwards.
The testcase is awkward, because (I suspect) of PR32873.
Spotted by inspection.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301890 91177308-0d34-0410-b5e6-96231b3b80d8
Because it was a callee-saved register, we automatically generated code
to spill and unspill its original value so that it is restored after the
function returns.
The problem is that this code was being generated before the epilogue.
The epilogue itself uses the Y register, which could be prematurely
restored by the CSR restoration process.
This removes R29R28 from the CSR list and changes the prologue/epilogue
code to handle it explicitly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301887 91177308-0d34-0410-b5e6-96231b3b80d8
This change caused buildbot failures, apparently because we're not
passing around types that InstSimplify is used to seeing. I'm not overly
familiar with InstSimplify, so I'm reverting this until I can figure out
what exactly is wrong.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301885 91177308-0d34-0410-b5e6-96231b3b80d8
Rename parameters and locals to CamelCase, doxygenize the header, and
run clang-format on the whole thing.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301883 91177308-0d34-0410-b5e6-96231b3b80d8
This tracks whether MaxCallFrameSize is computed yet. Ideally we would
assert and fail when the value is queried before it is computed, however
this fails various targets that need to be fixed first.
Differential Revision: https://reviews.llvm.org/D32570
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301851 91177308-0d34-0410-b5e6-96231b3b80d8
In the testcase attached, we believe %tmp1 implies %tmp4.
where:
br i1 %tmp1, label %bb2, label %bb7
br i1 %tmp4, label %bb5, label %bb7
because Wwhile looking at PredicateInfo stuffs we end up calling
isImpliedTrueByMatchingCmp() with the arguments backwards.
Differential Revision: https://reviews.llvm.org/D32718
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301849 91177308-0d34-0410-b5e6-96231b3b80d8
If we have ~(~X & Y), it only makes sense to transform it to (X | ~Y) when we do not need
the intermediate (~X & Y) value. In that case, we would need an extra instruction to
generate ~Y + 'or' (as shown in the test changes).
It's ok if we have multiple uses of ~X or Y, however. In those cases, we may not reduce the
instruction count or critical path, but we might improve throughput because we can generate
~X and ~Y in parallel. Whether that actually makes perf sense or not for a target is something
we can't answer in IR.
Differential Revision: https://reviews.llvm.org/D32703
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301848 91177308-0d34-0410-b5e6-96231b3b80d8
