Summary:
This patch implements copying some load commands that appear in executables/shared libraries such as the indirect symbol table.
I don't add tests intentionally because this patch is incomplete: we need a layout algorithm for executables/shared libraries. I'll submit it as a separate patch with tests.
Reviewers: alexshap, rupprecht, jhenderson, compnerd
Reviewed By: alexshap
Subscribers: abrachet, mgorny, mgrang, MaskRay, mtrent, jakehehrlich, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D63395
llvm-svn: 369230
Not sure how to test this as we have tests that exercise this code,
but nothing failed for the types not matching. Since all the k-registers
use equivalent register classes everything just ends up working.
llvm-svn: 369228
This allows us to widen the type when the KSHIFTR instruction
doesn't exist for the type. If we need to shift in zeroes into
the upper elements we would need more work to guarantee zeroes
when widening.
llvm-svn: 369227
We are currently missing this because shuffle canonicalization
puts the zero vector as V1 and the subvector as V2. Our current
code doesn't recognize this case.
llvm-svn: 369225
For such a case we should only need a KSHIFTL, but we were
previously generating a KSHIFTL followed by a KSHIFTR because
we mistakenly believed we need to zero the undef elements.
llvm-svn: 369224
Address post-commit comment on D66256 regarding the `else( MSVC )` block
containing only blocks guarded with `LLVM_COMPILER_IS_GCC_COMPATIBLE`,
which would imply `NOT MSVC`.
llvm-svn: 369221
Add similar functionality to isShuffleEquivalent - if the mask elements don't match, try matching the BUILD_VECTOR scalars instead.
As target shuffles need to handle SM_Sentinel values, this can get a bit tricky, so commit just adds actual mask element index handling - full SM_SentinelZero support will be added when the need arises.
Also, enables support in matchVectorShuffleWithPACK
llvm-svn: 369212
Simplifies shuffle mask comparisons by just bailing out if the shuffle mask has any out of range values - will make an upcoming patch much simpler.
llvm-svn: 369211
These were recently made simple types. This restores their
behavior back to something like their EVT legalization.
We might be able to fix the code in type legalization where the
assert was failing, but I didn't investigate too much as I had
already looked at the computeRegisterProperties code during the
review for v3i16/v3f16.
Most of the test changes restore the X86 codegen back to what
it looked like before the recent change. The test case in
vec_setcc.ll and is a reduced version of the reproducer from
the fuzzer.
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=16490
llvm-svn: 369205
Currently the searchable tables report the number of dwords. These
round to the same number for 3 and 4 component d16
instructions. Change this to report the number of elements so this
isn't ambiguous.
llvm-svn: 369202
Commit https://reviews.llvm.org/D57939 ("[DWARF] Refactor
RelocVisitor and fix computation of SHT_RELA-typed relocation entries)
made a change for relocation resolution when operating
on an object file.
The change unfortunately broke BPF as given SymbolValue (S) and
Addent (A), previously relocation is resolved to
S + A
and after the change, it is resolved to
S
This patch fixed the issue by resolving relocation correctly.
It looks not all relocation resolution reaches here and I did not
trace down exactly when. But I do find if the object file includes
codes in two different ELF sections than default ".text",
the above bug will be triggered.
This patch included a trivial two function source code to
demonstrate this issue. The relocation for .debug_loc is resolved
incorrectly due to this and llvm-objdump cannot display source
annotated assembly.
Differential Revision: https://reviews.llvm.org/D66372
llvm-svn: 369199
Fix: Add a `consumeError` call removed by mistake to 'printStackSize',
this should fix the "Expected<T> must be checked before access or destruction." reported by following bot:
http://lab.llvm.org:8011/builders/clang-x64-windows-msvc/builds/9743/steps/stage%201%20check/logs/stdio
Original commit message:
Currently we have the following functions for error reporting:
LLVM_ATTRIBUTE_NORETURN void reportError(Twine Msg);
void reportError(Error Err, StringRef Input);
void reportWarning(Twine Msg);
void reportWarning(StringRef Input, Error Err);
void warn(llvm::Error Err);
void error(std::error_code EC);
Problems are: naming is inconsistent, arguments order is inconsistent,
some of the functions looks excessive.
After applying this patch we have:
void reportError(Error Err, StringRef Input);
void reportError(std::error_code EC, StringRef Input);
void reportWarning(Error Err, StringRef Input);
I'd be happy to remove reportError(std::error_code EC, StringRef Input) too, but it
is used by COFF heavily.
Test cases were updated, they show an improvement introduced.
Differential revision: https://reviews.llvm.org/D66286
llvm-svn: 369194
Few BB failed with the following error:
Command Output (stderr):
--
/home/buildbots/ppc64be-clang-lnt-test/clang-ppc64be-lnt/llvm/test/tools/llvm-readobj/stack-sizes.test:263:19: error: BADSECTION-OUT: expected string not found in input
# BADSECTION-OUT: 8 ?
^
<stdin>:4:1: note: scanning from here
^
It doesn't reproduce on ubuntu/windows I have. Also, seems many of the bots
are happy too.
This slightly reorders the code to make fouts().flush() call earlier,
like it was before the r369191.
llvm-svn: 369192
Summary:
Fix a bug of preducessors.
In `block-placement` pass, it will create some patterns for unconditional we can do the simple early retrun.
But the `early-ret` pass is before `block-placement`, we don't want to run it again.
This patch is to do the simple early return to optimize the blocks at the last of `block-placement`.
Reviewed By: efriedma
Differential Revision: https://reviews.llvm.org/D63972
llvm-svn: 369191
urrently we have the following functions for error reporting:
--
LLVM_ATTRIBUTE_NORETURN void reportError(Twine Msg);
void reportError(Error Err, StringRef Input);
void reportWarning(Twine Msg);
void reportWarning(StringRef Input, Error Err);
void warn(llvm::Error Err);
void error(std::error_code EC);
---
Problems are: naming is inconsistent, arguments order is inconsistent,
some of the functions looks excessive.
After applying this patch we have:
---
LLVM_ATTRIBUTE_NORETURN void reportError(Error Err, StringRef Input);
LLVM_ATTRIBUTE_NORETURN void reportError(std::error_code EC, StringRef Input);
void reportWarning(Error Err, StringRef Input);
---
I'd be happy to remove reportError(std::error_code EC, StringRef Input) too, but it
is used by COFF heavily.
Test cases were updated, they show an improvement introduced.
Differential revision: https://reviews.llvm.org/D66286
llvm-svn: 369190
There are 2 similar openbsd-phdrs.elf-x86-64 objects committed and
used in test/Object and test/tools/llvm-objdump test cases.
There is no reason to have them, we can use YAML instead. Patch does that.
Differential revision: https://reviews.llvm.org/D66342
llvm-svn: 369189
raw_ostream has an is_displayed() member function that determines if the stream
is connected to a console for display or is connected to a file/pipe. By
default, is_displayed() returns false, and derived classes like raw_fd_ostream
override it. Because circular_raw_ostream wraps another stream, its result for
is_displayed() should be the same as that stream.
Differential Revision: https://reviews.llvm.org/D66026
llvm-svn: 369188
This patch applies only to the new pass manager.
Currently, when MSSA Analysis is available, and pass to each loop pass, it will be preserved by that loop pass.
Hence, mark the analysis preserved based on that condition, vs the current `EnableMSSALoopDependency`. This leaves the global flag to affect only the entry point in the loop pass manager (in FunctionToLoopPassAdaptor).
llvm-svn: 369181
This addresses the issue introduced in r369169, we need to unwrap
the value first before we can check whether it's empty. This also
swaps the two branches to put the common path first which should
be NFC.
llvm-svn: 369177
These data formatters make the string value appear in Xcode's
variables view (and on the command line) without having to expand the
data structure.
Differential Revision: https://reviews.llvm.org/D66354
llvm-svn: 369175
This reverts commit 5dbb90bfe14ace30224239cac7c61a1422fa5144.
As noted in the post-commit thread for r367891, this can create
a multiply that is lowered to a libcall that may not exist.
We need to improve the backend decomposition for integer multiply
before trying to re-land this (if it's still worthwhile after
doing the backend work).
llvm-svn: 369174
This is useful when trying to read notes from stripped files and matches
the behavior of GNU readelf and eu-readelf.
Differential Revision: https://reviews.llvm.org/D66358
llvm-svn: 369169
If OptimizeExtractBits() encountered a shift instruction with no operands at all,
it would erase the instruction, but still return false.
This previously didn’t matter because its caller would always return after
processing the instruction, but https://reviews.llvm.org/D63233 changed the
function’s caller to fall through if it returned false, which would then cause
a use-after-free detectable by ASAN.
This change makes OptimizeExtractBits return true if it removes a shift
instruction with no users, terminating processing of the instruction.
Patch by: @brentdax (Brent Royal-Gordon)
Differential Revision: https://reviews.llvm.org/D66330
llvm-svn: 369168
This reverts r368662 (git commit 1a8d790cf5f89c1df718844f13e934e39bef6ef5)
The compile-time regression repro is in https://bugs.llvm.org/show_bug.cgi?id=43024
llvm-svn: 369167
We currently don't use liveness information after this point, but it can
be useful to catch bugs using -verify-machineinstrs, and optimizations
could potentially use this information in the future.
Differential Revision: https://reviews.llvm.org/D66319
llvm-svn: 369162
By partially resolving returned calls we did not record that they were
not fully resolved which caused odd behavior down the line. We could
also end up with some, but not all, returned values of the callee in the
returned values map of the caller, another odd behavior we want to
avoid.
llvm-svn: 369160
