The section is described here:
https://refspecs.linuxfoundation.org/LSB_1.3.0/gLSB/gLSB/symverrqmts.html
Patch just teaches obj2yaml/yaml2obj to dump and parse such sections.
We did the finalization of string tables very late,
and I had to move the logic to make it a bit earlier.
That was needed in this patch since .gnu.version_r adds strings to .dynstr.
This might also be useful for implementing other special sections.
Everything else changed in this patch seems to be straightforward.
Differential revision: https://reviews.llvm.org/D58119
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@354328 91177308-0d34-0410-b5e6-96231b3b80d8
Re-organise calling convention tests to prepare for ilp32f and ilp32d hard
float ABI tests. It's also clear that we need to introduce similar tests for
lp64.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@354323 91177308-0d34-0410-b5e6-96231b3b80d8
Fix: move the test to x86 folder.
Seems it is needed, because llvm-objdump invocation used in test has -D (disasm) flag.
BB: http://lab.llvm.org:8011/builders/clang-hexagon-elf/builds/23016
/local/buildbot/slaves/hexagon-build-02/clang-hexagon-elf/stage1/bin/llvm-objdump:
error: '/local/buildbot/slaves/hexagon-build-02/clang-hexagon-elf/stage1/test/tools/llvm-objdump/Output/disasm-zeroes-relocations.test.tmp':
can't find target: : error: unable to get target for 'x86_64--', see --version and --triple.
.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@354322 91177308-0d34-0410-b5e6-96231b3b80d8
This is for -D -reloc combination.
With this patch, we do not skip the zero bytes that have a relocation against
them when -reloc is used. If -reloc is not used, then the behavior will be the same.
Differential revision: https://reviews.llvm.org/D58174
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@354319 91177308-0d34-0410-b5e6-96231b3b80d8
We are planning to be able to delete the current loop in LoopSimplifyCFG
in the future. Add API to notify the loop pass manager that it happened.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@354314 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
After (x,y) is inserted, depth-based search finds all affected v that satisfies:
depth(nca(x,y))+1 < depth(v) && there exists a path P from y to v where every w on P satisfies depth(v) <= depth(w)
This reduces to a widest path problem (maximizing the depth of the
minimum vertex in the path) which can be solved by a modified version of
Dijkstra with a bucket queue (named depth-based search in the paper).
The algorithm visits vertices in decreasing order of bucket number.
However, the current code misused priority_queue to extract them in
increasing order. I cannot think of a failing scenario but it surely may
process vertices more than once due to the local usage of Processed.
This patch fixes this bug and simplifies/optimizes the code a bit. Also
add more comments.
Reviewers: kuhar
Reviewed By: kuhar
Subscribers: kristina, jdoerfert, llvm-commits, NutshellySima, brzycki
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D58349
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@354306 91177308-0d34-0410-b5e6-96231b3b80d8
Legalize/select llvm.ctlz.*
Add select-ctlz to show that we actually select them. Update arm64-clrsb.ll and
arm64-vclz.ll to show that we perform valid transformations in optimized builds,
and document where GISel can improve.
Differential Revision: https://reviews.llvm.org/D58155
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@354299 91177308-0d34-0410-b5e6-96231b3b80d8
The motivating x86 cases for forming the intrinsic are shown in PR31754 and PR40487:
https://bugs.llvm.org/show_bug.cgi?id=31754https://bugs.llvm.org/show_bug.cgi?id=40487
..and those are shown in the IR test file and x86 codegen file.
Matching the usubo pattern is harder than uaddo because we have 2 independent values rather than a def-use.
This adds a TLI hook that should preserve the existing behavior for uaddo formation, but disables usubo
formation by default. Only x86 overrides that setting for now although other targets will likely benefit
by forming usbuo too.
Differential Revision: https://reviews.llvm.org/D57789
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@354298 91177308-0d34-0410-b5e6-96231b3b80d8
Similar to D57867 - this is a small patch with lots of test diffs.
With half-vector-width narrowing potential, using an extract + 128-bit vshufps
is a win because it replaces a 256-bit shuffle with a 128-bit shufle.
This seems like it should be a win even for targets with 'fast-variable-shuffle',
but we are intentionally deferring that to an independent change to make sure
that is true.
Differential Revision: https://reviews.llvm.org/D58181
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@354279 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit 079b610c29b4a428b3ae7b64dbac0378facf6632.
Bots are failing after this change on a stage 2 compile of clang.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@354277 91177308-0d34-0410-b5e6-96231b3b80d8
This patch fixes a bug where register writes performed by optimizable register
moves were sometimes wrongly treated like partial register updates. Before this
patch, llvm-mca wrongly predicted a 1.50 IPC for test reg-move-elimination-6.s
(added by this patch). With this patch, llvm-mca correctly updates the register
defintions in the PRF, and the IPC for that test is now correctly reported as 2.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@354271 91177308-0d34-0410-b5e6-96231b3b80d8
This is a follow-up to r354246 and a reimplementation of https://reviews.llvm.org/D57097?id=186600
that should not trigger any UB thanks to the use of an union.
This may still be subject to the problem solved by std::launder, but I'm unsure how it interacts whith union.
/me plans to revert if this triggers any relevant bot failure. At least this validates in Release mode with
clang 6.0.1 and gcc 4.8.5.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@354264 91177308-0d34-0410-b5e6-96231b3b80d8
Second attempt, trying to navigate out of the UB zone using
union for storage instead of raw bytes.
I'm prepared to revert that commit as soon as validation breaks,
which is likely to happen.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@354246 91177308-0d34-0410-b5e6-96231b3b80d8
This class is used for two difference tablegen generated tables. For one of the tables the Value FeatureBitset only has one bit set. For the other usage the Implies field was unused.
This patch changes the Value field to just be an unsigned. For the usage that put a real vector in bitset, we now use the previously unused Implies field and leave the Value field unused instead.
This is good for a 16K reduction in the size of llc on my local build with all targets enabled.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@354243 91177308-0d34-0410-b5e6-96231b3b80d8
Second attempt, trying to navigate out of the UB zone using
union for storage instead of raw bytes.
I'm prepared to revert that commit as soon as validation breaks,
which is likely to happen.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@354238 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: The C API don't have the bindings to create enumerators, needed to create an enumeration.
Reviewers: whitequark, CodaFi, harlanhaskins, deadalnix
Reviewed By: whitequark, CodaFi, harlanhaskins
Subscribers: hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D58323
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@354237 91177308-0d34-0410-b5e6-96231b3b80d8
The pattern-matching from rL354221 / rL354224 doesn't cover
these, so we're up to 8 different commuted possibilities.
There may still be 1 more variant of this pattern.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@354236 91177308-0d34-0410-b5e6-96231b3b80d8
No need for a separate stack slot. The lifetimes don't overlap.
Also fix the MachinePointerInfo for the final load after the integer conversion to indicate it came from the stack slot.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@354234 91177308-0d34-0410-b5e6-96231b3b80d8
This should be NFC in current use case of this method, but it will
help to use it for solving more compex tasks in follow-up patches.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@354227 91177308-0d34-0410-b5e6-96231b3b80d8
In preparation for supporting vector expansion.
Add an isPostTypeLegalization flag to makeLibCall(), because this
expansion relies on the legalized form using MERGE_VALUES. Drop
the corresponding variant of ExpandLibCall, which is no longer used.
Differential Revision: https://reviews.llvm.org/D58006
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@354226 91177308-0d34-0410-b5e6-96231b3b80d8
We want to use the sum in the icmp to allow matching with
m_UAddWithOverflow and eliminate the 'not'. This is discussed
in D51929 and is another step towards solving PR14613:
https://bugs.llvm.org/show_bug.cgi?id=14613
(The matching here is incomplete. Trying to take minimal steps
to make sure we don't induce infinite looping from existing
canonicalizations of the 'select'.)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@354221 91177308-0d34-0410-b5e6-96231b3b80d8
The LLVM Support library implementation has resided in
//llvm/lib/Support for a significant amount of time now,
with documentation having been updated with all references
to the "System library" being replaced with "Support library".
Since this file mirrors already existing documentation available
for Support library, includes dead links to documentation and
still refers to it as "System library", having it there is
confusing and updating it has very little point as it duplicates
information in documentation, except documentation is a lot more
up to date while this file has not been maintained.
Up to date documentation concerning this can be found here:
http://llvm.org/docs/SupportLibrary.html
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@354209 91177308-0d34-0410-b5e6-96231b3b80d8
George Rimar