Eric Astor [Tue, 8 Jun 2021 19:30:11 +0000 (15:30 -0400)]
[ms] [llvm-ml] Disambiguate size directives and variable declarations
MASM allows statements of the form:
<VAR> DWORD 5
to declare a variable with name <VAR>, while:
call dword ptr [<value>]
is a valid instruction. To disambiguate, we recognize size directives by the trailing "ptr" token.
As discussed in https://lists.llvm.org/pipermail/llvm-dev/2021-May/150774.html
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D103257
Michael Liao [Tue, 8 Jun 2021 18:35:36 +0000 (14:35 -0400)]
[amdgpu] Add `-enable-ocl-mangling-mismatch-workaround`.
- Add `-enable-ocl-mangling-mismatch-workaround` to work around the
mismatch on OCL name mangling so far.
Reviewed By: yaxunl, rampitec
Differential Revision: https://reviews.llvm.org/D103920
Leonard Chan [Tue, 8 Jun 2021 19:37:04 +0000 (12:37 -0700)]
Fix for failing test mentioned in https://reviews.llvm.org/D103564.
This updates the path shown in the stack trace.
Alex Langford [Thu, 3 Jun 2021 19:14:20 +0000 (12:14 -0700)]
[lldb][NFC] Refactor name to index maps in Symtab
The various maps in Symtab lead to some repetative code. This should
improve the situation somewhat.
Differential Revision: https://reviews.llvm.org/D103652
Sanjay Patel [Tue, 8 Jun 2021 19:12:41 +0000 (15:12 -0400)]
[CodeGen] remove instcombine from codegen tests; NFC
The FileCheck lines in these files are auto-generated and complete,
so there's very little upside (less CHECK lines) from running
-instcombine on them and violating the expected test layering
(optimizer developers shouldn't have to be aware of clang tests).
Running opt passes like this makes it harder to make changes such as:
D93817
Petr Hosek [Tue, 8 Jun 2021 18:38:40 +0000 (11:38 -0700)]
[CMake][Fuchsia] Use PIC for Fuchsia runtimes
Disabling PIC globally also disabled PIC for runtimes which was
undesirable, manually override it.
Differential Revision: https://reviews.llvm.org/D103919
Nico Weber [Tue, 8 Jun 2021 19:21:03 +0000 (15:21 -0400)]
[gn build] (semi-manually) port
944b3c53aec5
Leonard Chan [Mon, 7 Jun 2021 22:35:28 +0000 (15:35 -0700)]
[NFC][compiler-rt][hwasan] Move allocation functions into their own file
This removes the `__sanitizer_*` allocation function definitions from
`hwasan_interceptors.cpp` and moves them into their own file. This way
implementations that do not use interceptors at all can just ignore
(almost) everything in `hwasan_interceptors.cpp`.
Also remove some unused headers in `hwasan_interceptors.cpp` after the move.
Differential Revision: https://reviews.llvm.org/D103564
Abhina Sreeskantharajan [Tue, 8 Jun 2021 18:44:45 +0000 (14:44 -0400)]
[SystemZ][z/OS] Pass OpenFlags when creating tmp files
This patch https://reviews.llvm.org/D102876 caused some lit regressions on z/OS because tmp files were no longer being opened based on binary/text mode. This patch passes OpenFlags when creating tmp files so we can open files in different modes.
Reviewed By: amccarth
Differential Revision: https://reviews.llvm.org/D103806
Matt Arsenault [Mon, 7 Jun 2021 22:57:03 +0000 (18:57 -0400)]
GlobalISel: Avoid use of G_INSERT in insertParts
G_INSERT legalization is incomplete and doesn't work very
well. Instead try to use sequences of G_MERGE_VALUES/G_UNMERGE_VALUES
padding with undef values (although this can get pretty large).
For the case of load/store narrowing, this is still performing the
load/stores in irregularly sized pieces. It might be cleaner to split
this down into equal sized pieces, and rely on load/store merging to
optimize it.
Matt Arsenault [Mon, 7 Jun 2021 21:01:03 +0000 (17:01 -0400)]
GlobalISel: Hide virtual register creation in MIRBuilder
David Green [Tue, 8 Jun 2021 18:39:45 +0000 (19:39 +0100)]
[ARM] A couple of extra VMOVimm tests, useful for showing BE codegen. NFC
Mehdi Amini [Tue, 8 Jun 2021 18:28:39 +0000 (18:28 +0000)]
Add a static assertions for custom Op<> to not defined data members (NFC)
A common mistake for newcomers to MLIR is to try to store extra member
on the Op class. However these are intended to be thing wrapper around
an Operation*, all the storage is meant to be encoded in attribute on
the underlying Operation. This can be confusing to debug, so better
catch it at build time.
Reviewed By: ftynse
Differential Revision: https://reviews.llvm.org/D103869
Artur Pilipenko [Tue, 8 Jun 2021 18:26:27 +0000 (11:26 -0700)]
Add an option to hide "cold" blocks from CFG graph
Introduce a new cl::opt to hide "cold" blocks from CFG DOT graphs.
Use BFI to get block relative frequency. Hide the block if the
frequency is below the threshold set by the command line option value.
Reviewed By: davidxl, hoy
Differential Revision: https://reviews.llvm.org/D103640
Petr Hosek [Tue, 8 Jun 2021 18:01:58 +0000 (11:01 -0700)]
[CMake][Fuchsia] Include llvm-otool in Fuchsia toolchain
We want to use llvm-otool in our build.
Differential Revision: https://reviews.llvm.org/D103918
Craig Topper [Tue, 8 Jun 2021 18:13:18 +0000 (11:13 -0700)]
[RISCV] Remove dead code from fixed-vectors-abs.ll test cases. NFC
We had two pointer arguments and a dead load presumably copied
from a binary operation test and modified into unary abs.
Justin Bogner [Tue, 8 Jun 2021 18:14:33 +0000 (11:14 -0700)]
[FuzzMutate] Fix getWeight of InstDeleterIRStrategy
The comment states the following, for calculating the Line variable:
> Draw a line starting from when we only have 1k left and increasing
> linearly to double the current weight.
However, the value was not calculated as described. Instead, it would
result in a negative value, which resulted in the function always
returning 0 afterwards.
```
// Invariant: CurrentSize <= MaxSize - 200
// Invariant: CurrentWeight >= 0
int Line = (-2 * CurrentWeight) * (MaxSize - CurrentSize + 1000);
// {Line <= 0}
```
This commit fixes the issue and linearly interpolates as described.
Patch by Loris Reiff. Thanks!
Differential Revision: https://reviews.llvm.org/D96207
Nathan Sidwell [Wed, 5 May 2021 15:55:02 +0000 (08:55 -0700)]
[clang] p1099 using enum part 2
This implements the 'using enum maybe-qualified-enum-tag ;' part of
1099. It introduces a new 'UsingEnumDecl', subclassed from
'BaseUsingDecl'. Much of the diff is the boilerplate needed to get the
new class set up.
There is one case where we accept ill-formed, but I believe this is
merely an extended case of an existing bug, so consider it
orthogonal. AFAICT in class-scope the c++20 rule is that no 2 using
decls can bring in the same target decl ([namespace.udecl]/8). But we
already accept:
struct A { enum { a }; };
struct B : A { using A::a; };
struct C : B { using A::a;
using B::a; }; // same enumerator
this patch permits mixtures of 'using enum Bob;' and 'using Bob::member;' in the same way.
Differential Revision: https://reviews.llvm.org/D102241
Petr Hosek [Tue, 8 Jun 2021 17:47:23 +0000 (10:47 -0700)]
[CMake] Only include LTO on Apple targets
We only need libLTO when using ld64.
Differential Revision: https://reviews.llvm.org/D103916
Nick Desaulniers [Tue, 8 Jun 2021 15:57:12 +0000 (08:57 -0700)]
reland [IR] make -stack-alignment= into a module attr
Relands commit
433c8d950cb3a1fa0977355ce0367e8c763a3f13 with fixes for
MIPS.
Similar to D102742, specifying the stack alignment via CodegenOpts means
that this flag gets dropped during LTO, unless the command line is
re-specified as a plugin opt. Instead, encode this information as a
module level attribute so that we don't have to expose this llvm
internal flag when linking the Linux kernel with LTO.
Looks like external dependencies might need a fix:
* https://github.com/llvm-hs/llvm-hs/issues/345
* https://github.com/halide/Halide/issues/6079
Link: https://github.com/ClangBuiltLinux/linux/issues/1377
Reviewed By: tejohnson
Differential Revision: https://reviews.llvm.org/D103048
Daniel McIntosh [Tue, 8 Jun 2021 17:59:11 +0000 (13:59 -0400)]
[libcxx] Remove VLA from libcxx locale header
The buffer size (`__nbuf`) in `num_put::do_put` is currently not an
integral/core constant expression. As a result, `__nar` is a Variable Length
Array (VLA). VLAs are a GNU extension and not part of the base C++ standard, so
unless there is good reason to do so they probably shouldn't be used in any of
the standard library headers. The call to `__iob.flags()` is the only thing
keeping `__nbuf` from being a compile time constant, so the solution here is to
simply err on the side of caution and always allocate a buffer large enough to
fit the base prefix.
Note that, while the base prefix for hex (`0x`) is slightly longer than the
base prefix for octal (`0`), this isn't a concern. The difference in the space
needed for the value portion of the string is enough to make up for this.
(Unless we're working with small, oddly sized types such as a hypothetical
`uint9_t`, the space needed for the value portion in octal is at least 1 more
than the space needed for the value portion in hex).
This PR also adds `constexpr` to `__nbuf` to enforce compile time const-ness
going forward.
Reviewed By: Mordante, #libc, Quuxplusone, ldionne
Differential Revision: https://reviews.llvm.org/D103558
Louis Dionne [Wed, 2 Jun 2021 21:07:57 +0000 (17:07 -0400)]
[libc++] Add a CI configuration for the modular build
Differential Revision: https://reviews.llvm.org/D103559
Justin Bogner [Tue, 2 Mar 2021 22:46:03 +0000 (14:46 -0800)]
[GlobalISel] Handle non-multiples of the base type in narrowScalarAddSub
When narrowing G_ADD and G_SUB, handle types that aren't a multiple of
the type we're narrowing to. This allows us to handle types like s96
on 64 bit targets.
Note that the test here has a couple of dead instructions because of
the way the setup legalizes. I wasn't able to come up with a way to
write this test that avoids that easily.
Differential Revision: https://reviews.llvm.org/D97811
Justin Bogner [Tue, 2 Mar 2021 17:49:15 +0000 (09:49 -0800)]
[GlobalISel] Handle non-multiples of the base type in narrowScalarInsert
When narrowing G_INSERT, handle types that aren't a multiple of the
type we're narrowing to. This comes up if we're narrowing something
like an s96 to fit in 64 bit registers and also for non-byte multiple
packed types if they come up.
This implementation handles these cases by extending the extra bits to
the narrow size and truncating the result back to the destination
size.
Differential Revision: https://reviews.llvm.org/D97791
Mehdi Amini [Tue, 8 Jun 2021 17:08:30 +0000 (17:08 +0000)]
Add missing header <atomic> in lib/IR/Verifier.cpp (NFC)
Fix the build on some platform.
Petr Hosek [Tue, 8 Jun 2021 08:03:26 +0000 (01:03 -0700)]
[Fuchsia] Update some of the Fuchsia toolchain flags
This should make the build more self-contained.
Differential Revision: https://reviews.llvm.org/D103875
Mehdi Amini [Tue, 8 Jun 2021 17:01:05 +0000 (17:01 +0000)]
Revert "[llvm] Make Sequence reverse-iterable"
This reverts commit
e772216e708937988c039420d2c559568f91ae27
(and fixup
7f6c878a2c035eb6325ab228d9bc2d257509d959).
The build is broken with gcc5 host compiler:
In file included from
from mlir/lib/Dialect/Utils/StructuredOpsUtils.cpp:9:
tools/mlir/include/mlir/IR/BuiltinAttributes.h.inc:424:57: error: type/value mismatch at argument 1 in template parameter list for 'template<class ItTy, class FuncTy, class FuncReturnTy> class llvm::mapped_iterator'
std::function<T(ptrdiff_t)>>;
^
tools/mlir/include/mlir/IR/BuiltinAttributes.h.inc:424:57: note: expected a type, got 'decltype (seq<ptrdiff_t>(0, 0))::const_iterator'
Simon Pilgrim [Tue, 8 Jun 2021 16:33:59 +0000 (17:33 +0100)]
Use llvm_unreachable for unsupported integer types.
As suggested on rG937c4cffd024, use llvm_unreachable for unhandled integer types (which shouldn't be possible) instead of breaking and dropping down to the existing fatal error handler.
Helps silence static analyzer warnings.
Simon Pilgrim [Tue, 8 Jun 2021 16:08:14 +0000 (17:08 +0100)]
PPCISelLowering.cpp - don't dereference a dyn_cast<>.
dyn_cast<> can return nullptr which we would then dereference - use cast<> which will assert that the type is correct.
Simon Pilgrim [Tue, 8 Jun 2021 15:42:28 +0000 (16:42 +0100)]
InstrEmitter.cpp - don't dereference a dyn_cast<>.
dyn_cast<> can return nullptr which we would then dereference - use cast<> which will assert that the type is correct.
Brendon Cahoon [Tue, 1 Jun 2021 20:38:42 +0000 (16:38 -0400)]
[AMDGPU] Add gfx1013 target
Differential Revision: https://reviews.llvm.org/D103663
Chris Lattner [Sat, 5 Jun 2021 18:38:31 +0000 (11:38 -0700)]
[Core] Add Twine support for StringAttr and Identifier. NFC.
This is both more efficient and more ergonomic than going
through an std::string, e.g. when using llvm::utostr and
in string concat cases.
Unfortunately we can't just overload ::get(). This causes an
ambiguity because both twine and stringref implicitly convert
from std::string.
Differential Revision: https://reviews.llvm.org/D103754
Chris Lattner [Sun, 30 May 2021 00:08:33 +0000 (17:08 -0700)]
[Verifier] Speed up and parallelize dominance checking. NFC
One of the key algorithms used in the "mlir::verify(op)" method is the
dominance checker, which ensures that operand values properly dominate
the operations that use them.
The MLIR dominance implementation has a number of algorithmic problems,
and is not really set up in general to answer dense queries: it's constant
factors are really slow with multiple map lookups and scans, even in the
easy cases. Furthermore, when calling mlir::verify(module) or some other
high level operation, it makes sense to parallelize the dominator
verification of all the functions within the module.
This patch has a few changes to enact this:
1) It splits dominance checking into "IsolatedFromAbove" units. Instead
of building a monolithic DominanceInfo for everything in a module,
for example, it checks dominance for the module to all the functions
within it (noop, since there are no operands at this level) then each
function gets their own DominanceInfo for each of their scope.
2) It adds the ability for mlir::DominanceInfo (and post dom) to be
constrained to an IsolatedFromAbove region. There is no reason to
recurse into IsolatedFromAbove regions since use/def relationships
can't span this region anyway. This is already checked by the time
the verifier gets here.
3) It avoids querying DominanceInfo for trivial checks (e.g. intra Block
references) to eliminate constant factor issues).
4) It switches to lazily constructing DominanceInfo because the trivial
check case handles the vast majority of the cases and avoids
constructing DominanceInfo entirely in some cases (e.g. at the module
level or for many Regions's that contain a single Block).
5) It parallelizes analysis of collections IsolatedFromAbove operations,
e.g. each of the functions within a Module.
All together this is more than a 10% speedup on `firtool` in circt on a
large design when run in -verify-each mode (our default) since the verifier
is invoked after each pass.
Still todo is to parallelize the main verifier pass. I decided to split
this out to its own thing since this patch is already large-ish.
Differential Revision: https://reviews.llvm.org/D103373
Craig Topper [Tue, 8 Jun 2021 16:31:30 +0000 (09:31 -0700)]
Further improve register allocation for vwadd(u).wv, vwsub(u).wv, vfwadd.wv, and vfwsub.wv.
The first source has the same EEW as the destination, but we're
using earlyclobber which prevents them from ever being the same
register. This patch attempts to work around this.
-For unmasked .wv, add a special TIED pseudo that pretends like
the first operand and the destination must be the same register. This
disables the earlyclobber for that source. Mark the instruction
as convertible to 3 address form which will switch it to the
original untied pseudo when the TwoAddressInstructionPass decides
that keeping them tied would require an extra copy. This uses
code in RISCVInstrInfo.cpp to do the conversion to the untied
opcode.
The untie test case show that we can generate the untied version.
Not sure it was profitable to do it in this case, but they have
really simple IR.
Reviewed By: arcbbb
Differential Revision: https://reviews.llvm.org/D103552
Jake Vossen [Tue, 8 Jun 2021 16:32:05 +0000 (12:32 -0400)]
Fix a typo in the internals manual
Craig Topper [Tue, 8 Jun 2021 16:14:26 +0000 (09:14 -0700)]
[RISCV] Remove ForceTailAgnostic flag from vmv.s.x, vfmv.s.f and reductions.
In 0.9 these were defined to leave elements other than 0 in the
destination unmodified. They were changed to use the tail policy
in 0.10. I missed that update.
I assume no one has noticed because in order cores treat tail
agnostic the same as tail undisturbed. I believe Spike and QEMU do
the same.
Reviewed By: arcbbb, frasercrmck
Differential Revision: https://reviews.llvm.org/D103736
Fangrui Song [Tue, 8 Jun 2021 16:22:30 +0000 (09:22 -0700)]
[ELF] Add a GRP_COMDAT test with a local signature symbol
See https://groups.google.com/g/generic-abi/c/2X6mR-s2zoc
Test that a local signature symbol does not suppress COMDAT deduplication.
Kiran Chandramohan [Tue, 8 Jun 2021 15:48:57 +0000 (16:48 +0100)]
[MLIR] Remove LLVM_AnyInteger type constraint
LLVM Dialect uses builtin-integer types. The existing LLVM_AnyInteger
type constraint is a dupe of AnyInteger. This patch removes LLVM_AnyInteger
and replaces all usage with AnyInteger.
Reviewed By: ftynse
Differential Revision: https://reviews.llvm.org/D103839
Louis Dionne [Tue, 8 Jun 2021 16:12:04 +0000 (12:12 -0400)]
[libc++] NFC: Add regression tests for some <tuple> PRs that have been fixed
Hans Wennborg [Tue, 8 Jun 2021 15:51:05 +0000 (17:51 +0200)]
[clang-cl] Parse the /external: flags (PR36003)
They are still unsupported, but at least this makes clang-cl not mistake
them for being filenames.
As pointed out in the bug, VS 16.10 now uses these flags in new projects
by default.
Nick Desaulniers [Tue, 8 Jun 2021 15:55:50 +0000 (08:55 -0700)]
Revert "[IR] make -stack-alignment= into a module attr"
This reverts commit
433c8d950cb3a1fa0977355ce0367e8c763a3f13.
Breaks the MIPS build.
William S. Moses [Mon, 7 Jun 2021 17:44:07 +0000 (13:44 -0400)]
[MLIR][MemRef] Only allow fold of cast for the pointer operand, not the value
Currently canonicalizations of a store and a cast try to fold all casts into the store.
In the case where the operand being stored is itself a cast, this is illegal as the type of the value being stored
will change. This PR fixes this by not checking the value for folding with a cast.
Depends on https://reviews.llvm.org/D103828
Differential Revision: https://reviews.llvm.org/D103829
David Blaikie [Tue, 8 Jun 2021 15:30:48 +0000 (08:30 -0700)]
.clang-tidy: Disable misc-no-recursion in general/across the monorepo
Nick Desaulniers [Tue, 8 Jun 2021 15:22:48 +0000 (08:22 -0700)]
[IR] make -stack-alignment= into a module attr
Similar to D102742, specifying the stack alignment via CodegenOpts means
that this flag gets dropped during LTO, unless the command line is
re-specified as a plugin opt. Instead, encode this information as a
module level attribute so that we don't have to expose this llvm
internal flag when linking the Linux kernel with LTO.
Looks like external dependencies might need a fix:
* https://github.com/llvm-hs/llvm-hs/issues/345
* https://github.com/halide/Halide/issues/6079
Link: https://github.com/ClangBuiltLinux/linux/issues/1377
Reviewed By: tejohnson
Differential Revision: https://reviews.llvm.org/D103048
David Blaikie [Mon, 7 Jun 2021 20:56:02 +0000 (13:56 -0700)]
NFC: .clang-tidy: Inherit configs from parents to improve maintainability
In the interests of disabling misc-no-recursion across LLVM (this seems
like a stylistic choice that is not consistent with LLVM's
style/development approach) this NFC preliminary change adjusts all the
.clang-tidy files to inherit from their parents as much as possible.
This change specifically preserves all the quirks of the current configs
in order to make it easier to review as NFC.
I validatad the change is NFC as follows:
for X in `cat ../files.txt`;
do
mkdir -p ../tmp/$(dirname $X)
touch $(dirname $X)/blaikie.cpp
clang-tidy -dump-config $(dirname $X)/blaikie.cpp > ../tmp/$(dirname $X)/after
rm $(dirname $X)/blaikie.cpp
done
(similarly for the "before" state, without this patch applied)
for X in `cat ../files.txt`;
do
echo $X
diff \
../tmp/$(dirname $X)/before \
<(cat ../tmp/$(dirname $X)/after \
| sed -e "s/,readability-identifier-naming\(.*\),-readability-identifier-naming/\1/" \
| sed -e "s/,-llvm-include-order\(.*\),llvm-include-order/\1/" \
| sed -e "s/,-misc-no-recursion\(.*\),misc-no-recursion/\1/" \
| sed -e "s/,-clang-diagnostic-\*\(.*\),clang-diagnostic-\*/\1/")
done
(using sed to strip some add/remove pairs to reduce the diff and make it easier to read)
The resulting report is:
.clang-tidy
clang/.clang-tidy
2c2
< Checks: 'clang-diagnostic-*,clang-analyzer-*,-*,clang-diagnostic-*,llvm-*,misc-*,-misc-unused-parameters,-misc-non-private-member-variables-in-classes,-readability-identifier-naming,-misc-no-recursion'
---
> Checks: 'clang-diagnostic-*,clang-analyzer-*,-*,clang-diagnostic-*,llvm-*,misc-*,-misc-unused-parameters,-misc-non-private-member-variables-in-classes,-misc-no-recursion'
compiler-rt/.clang-tidy
2c2
< Checks: 'clang-diagnostic-*,clang-analyzer-*,-*,clang-diagnostic-*,llvm-*,-llvm-header-guard,misc-*,-misc-unused-parameters,-misc-non-private-member-variables-in-classes'
---
> Checks: 'clang-diagnostic-*,clang-analyzer-*,-*,clang-diagnostic-*,llvm-*,misc-*,-misc-unused-parameters,-misc-non-private-member-variables-in-classes,-llvm-header-guard'
flang/.clang-tidy
2c2
< Checks: 'clang-diagnostic-*,clang-analyzer-*,-*,llvm-*,-llvm-include-order,misc-*,-misc-no-recursion,-misc-unused-parameters,-misc-non-private-member-variables-in-classes'
---
> Checks: 'clang-diagnostic-*,clang-analyzer-*,-*,llvm-*,misc-*,-misc-unused-parameters,-misc-non-private-member-variables-in-classes,-llvm-include-order,-misc-no-recursion'
flang/include/flang/Lower/.clang-tidy
flang/include/flang/Optimizer/.clang-tidy
flang/lib/Lower/.clang-tidy
flang/lib/Optimizer/.clang-tidy
lld/.clang-tidy
lldb/.clang-tidy
llvm/tools/split-file/.clang-tidy
mlir/.clang-tidy
The `clang/.clang-tidy` change is a no-op, disabling an option that was never enabled.
The compiler-rt and flang changes are no-op reorderings of the same flags.
(side note, the .clang-tidy file in parallel-libs is broken and crashes
clang-tidy because it uses "lowerCase" as the style instead of "lower_case" -
so I'll deal with that separately)
Differential Revision: https://reviews.llvm.org/D103842
Louis Dionne [Tue, 8 Jun 2021 15:15:27 +0000 (11:15 -0400)]
[libc++] Remove the old HTML documentation
This commit finishes moving the <atomic> design documents to the RST
documentation and removes the old documentation. https://libcxx.llvm.org
is already pointing to the new documentation only now, so the removal of
the old documentation is really a NFC.
I went over the old documentation and I don't think we're leaving anything
important behind - I think everything important was mentionned in the RST
documentation anyway.
patacca [Tue, 8 Jun 2021 15:12:10 +0000 (17:12 +0200)]
Revert "[Polly][Isl] Removing nullptr constructor from C++ bindings. NFC."
This reverts commit
be5e2fc7bf781c7fc079943552ea1b519f45c815.
This introduced a building error for polly. https://lab.llvm.org/buildbot#builders/10/builds/4951
Simon Pilgrim [Tue, 8 Jun 2021 14:49:27 +0000 (15:49 +0100)]
[DAG] foldShuffleOfConcatUndefs - ensure shuffles of upper (undef) subvector elements is undef (PR50609)
shuffle(concat(x,undef),concat(y,undef)) -> concat(shuffle(x,y),shuffle(x,y))
If the original shuffle references any of the upper (undef) subvector elements, ensure the split shuffle masks uses undef instead of an out-of-bounds value.
Fixes PR50609
Whitney Tsang [Tue, 8 Jun 2021 14:46:20 +0000 (14:46 +0000)]
[LoopNest] Fix Wdeprecated-copy warnings
error: definition of implicit copy constructor for 'LoopNest' is
deprecated because it has a user-declared copy assignment operator
[-Werror,-Wdeprecated-copy]
LoopNest &operator=(const LoopNest &) = delete;
Reviewed By: Meinersbur
Differential Revision: https://reviews.llvm.org/D103752
Yaxun (Sam) Liu [Mon, 7 Jun 2021 19:01:25 +0000 (15:01 -0400)]
[CUDA][HIP] Fix store of vtbl in ctor
vtbl itself is in default global address space. When clang emits
ctor, it gets a pointer to the vtbl field based on the this pointer,
then stores vtbl to the pointer.
Since this pointer can point to any address space (e.g. an object
created in stack), this pointer points to default address space, therefore
the pointer to vtbl field in this object should also be in default
address space.
Currently, clang incorrectly casts the pointer to vtbl field in this object
to global address space. This caused assertions in backend.
This patch fixes that by removing the incorrect addr space cast.
Reviewed by: Artem Belevich
Differential Revision: https://reviews.llvm.org/D103835
Guillaume Chatelet [Tue, 8 Jun 2021 14:11:54 +0000 (14:11 +0000)]
Fix missing header and namespace qualifier in ADT Sequence
patacca [Tue, 8 Jun 2021 13:24:21 +0000 (15:24 +0200)]
[Polly][Isl] Removing nullptr constructor from C++ bindings. NFC.
[Polly][Isl] Removing nullptr constructor from C++ bindings. NFC.
This is part of an effort to reduce the differences between the custom C++ bindings used right now by polly in `lib/External/isl/include/isl/isl-noxceptions.h` and the official isl C++ interface.
Changes made:
- Removed `std::nullptr_t` constructor from all the classes in the isl C++ bindings.
- `isl-noexceptions.h` has been generated by this https://github.com/patacca/isl/commit/
a7e00bea38f251a4bcf5c2c6ce5fa7ee5f661528
Reviewed By: Meinersbur
Differential Revision: https://reviews.llvm.org/D103751
Guillaume Chatelet [Tue, 8 Jun 2021 13:18:57 +0000 (13:18 +0000)]
[llvm] Make Sequence reverse-iterable
This patch simplifies the implementation of Sequence and makes it compatible with llvm::reverse.
It exposes the reverse iterators through rbegin/rend which prevents a dangling reference in std::reverse_iterator::operator++().
Differential Revision: https://reviews.llvm.org/D102679
Hans Wennborg [Tue, 8 Jun 2021 12:42:11 +0000 (14:42 +0200)]
Revert "3rd Reapply "[DebugInfo] Use variadic debug values to salvage BinOps and GEP instrs with non-const operands""
> This reapplies
c0f3dfb9, which was reverted following the discovery of
> crashes on linux kernel and chromium builds - these issues have since
> been fixed, allowing this patch to re-land.
This reverts commit
36ec97f76ac0d8be76fb16ac521f55126766267d.
The change caused non-determinism in the compiler, see comments on the code
review at https://reviews.llvm.org/D91722.
Reverting to unbreak people's builds until that can be addressed.
This also reverts the follow-up "[DebugInfo] Limit the number of values
that may be referenced by a dbg.value" in
a0bd6105d80698c53ceaa64bbe6e3b7e7bbf99ee.
Fabian Schuiki [Mon, 7 Jun 2021 15:33:23 +0000 (17:33 +0200)]
[MLIR] Mark additional builtin attr methods const
* Mark the following methods const:
* `ArrayAttr::getAsRange`
* `ArrayAttr::getAsValueRange`
* `DictionaryAttr::getAs`
* Make `DictionarAttr::getAs` generic over the name class, such that
`Identifier` and `StringRef` arguments get forwarded to the underlying
call to `get`. (Made generic to avoid introducing a dependency on
`include/mlir/IR/Identifier.h` as per the diff discussion.)
Reviewed By: rriddle
Differential Revision: https://reviews.llvm.org/D103822
Simon Moll [Tue, 8 Jun 2021 11:51:10 +0000 (13:51 +0200)]
[VP] getDeclarationForParams
`VPIntrinsic::getDeclarationForParams` creates a vp intrinsic
declaration for parameters you want to call it with. This is in
preparation of a new builder class that makes emitting vp intrinsic code
nearly as convenient as using a plain ir builder (aka `VectorBuilder`,
to be used by D99750).
Reviewed By: frasercrmck, craig.topper, vkmr
Differential Revision: https://reviews.llvm.org/D102686
Timm Bäder [Tue, 8 Jun 2021 10:33:40 +0000 (12:33 +0200)]
[NFC] Remove some include cycles
These files include themselves directly.
Simon Moll [Tue, 8 Jun 2021 11:55:21 +0000 (13:55 +0200)]
[VE][NFC] IRBuilder<> -> IRBuilderBase
VE's TTI broke with the switch from IRBuilder<> to IRBuilderBase.
Following that change to compile again.
Nathan Sidwell [Tue, 4 May 2021 14:59:17 +0000 (07:59 -0700)]
[clang] p1099 using enum part 1
This adds support for p1099's 'using SCOPED_ENUM::MEMBER;'
functionality, bringing a member of an enumerator into the current
scope. The novel feature here, is that there need not be a class
hierarchical relationship between the current scope and the scope of
the SCOPED_ENUM. That's a new thing, the closest equivalent is a
typedef or alias declaration. But this means that
Sema::CheckUsingDeclQualifier needs adjustment. (a) one can't call it
until one knows the set of decls that are being referenced -- if
exactly one is an enumerator, we're in the new territory. Thus it
needs calling later in some cases. Also (b) there are two ways we hold
the set of such decls. During parsing (or instantiating a dependent
scope) we have a lookup result, and during instantiation we have a set
of shadow decls. Thus two optional arguments, at most one of which
should be non-null.
Differential Revision: https://reviews.llvm.org/D100276
maekawatoshiki [Tue, 8 Jun 2021 11:29:48 +0000 (20:29 +0900)]
[LoopUnrollAndJam] Change LoopUnrollAndJamPass to LoopNest pass
This patch changes LoopUnrollAndJamPass from FunctionPass to LoopNest pass.
The next patch will utilize LoopNest to effectively handle loop nests.
Also, a crash problem on legacy pass manager is fixed.
Reviewed By: Whitney
Differential Revision: https://reviews.llvm.org/D99149
Vignesh Balasubramanian [Tue, 8 Jun 2021 11:03:39 +0000 (16:33 +0530)]
[OpenMP][OMPD] Implementation of OMPD debugging library - libompd.
This is the first of seven patches that implements OMPD, a debugging interface to support debugging of OpenMP programs.
It contains support code required in "openmp/runtime" for OMPD implementation.
Reviewed By: @hbae
Differential Revision: https://reviews.llvm.org/D100181
Kerry McLaughlin [Tue, 8 Jun 2021 09:49:22 +0000 (10:49 +0100)]
[CostModel] Return an invalid cost for memory ops with unsupported types
Fixes getTypeConversion to return `TypeScalarizeScalableVector` when a scalable vector
type cannot be legalized by widening/splitting. When this is the method of legalization
found, getTypeLegalizationCost will return an Invalid cost.
The getMemoryOpCost, getMaskedMemoryOpCost & getGatherScatterOpCost functions already call
getTypeLegalizationCost and will now also return an Invalid cost for unsupported types.
Reviewed By: sdesmalen, david-arm
Differential Revision: https://reviews.llvm.org/D102515
Sven van Haastregt [Tue, 8 Jun 2021 10:50:29 +0000 (11:50 +0100)]
[OpenCL] Add memory_scope_all_devices
Add the `memory_scope_all_devices` enum value, which is restricted to
OpenCL 3.0 or newer and the `__opencl_c_atomic_scope_all_devices`
feature. Also guard `memory_scope_all_svm_devices` accordingly, which
is already available in OpenCL 2.0.
The `__opencl_c_atomic_scope_all_devices` feature is header-only, so
set its define to 1 in `opencl-c-base.h`. This is done
unconditionally at the moment, as the mechanism for disabling
header-only options hasn't been decided yet.
This patch only adds a negative test for now. Ideally adding a CL3.0
run line to atomic-ops.cl should suffice as a positive test, but we
cannot do that yet until (at least) generic address spaces and program
scope variables are supported in OpenCL 3.0 mode.
Differential Revision: https://reviews.llvm.org/D103241
Fraser Cormack [Tue, 8 Jun 2021 10:05:09 +0000 (11:05 +0100)]
[RISCV] Add a test case showing inefficient vector codegen
Caroline Concatto [Tue, 11 May 2021 14:22:27 +0000 (15:22 +0100)]
[InstCombine] Add instcombine fold for extractelement + splat for scalable vectors
This patch allows that scalable vector can also use the fold that already
exists for fixed vector, only when the lane index is lower than the minimum
number of elements of the vector.
Differential Revision: https://reviews.llvm.org/D102404
Simon Pilgrim [Mon, 7 Jun 2021 17:19:44 +0000 (18:19 +0100)]
OptBisect.cpp - remove unused include. NFCI.
StringRef.h is included in OptBisect.h and we have no uses of std::string.
Simon Pilgrim [Mon, 7 Jun 2021 17:01:55 +0000 (18:01 +0100)]
[CostModel][X86] Improve AVX1/AVX2 truncation costs
Based off the worse case numbers generated by D103695, we were overestimating the cost of a number of vector truncations:
AVX2: v2i32->v2i8, v2i64->v2i16 + v4i64->v4i32
AVX1: v2i32->v2i8, v4i64->v4i16 + v16i16->v16i8
Once we have a working set of conversion costs, the intention is to cleanup the tables and use legalized types a lot more to reduce the number of entries we currently have.
Simon Pilgrim [Mon, 7 Jun 2021 16:15:55 +0000 (17:15 +0100)]
MemCpyOptimizer.cpp - hasUndefContentsMSSA - Pass DataLayout by reference. NFCI.
Simon Pilgrim [Mon, 7 Jun 2021 16:10:59 +0000 (17:10 +0100)]
ValueTrackingTest.cpp - Pass DataLayout by reference. NFCI.
Simon Pilgrim [Mon, 7 Jun 2021 16:10:19 +0000 (17:10 +0100)]
NVPTXTargetLowering::LowerReturn - Pass DataLayout by reference. NFCI.
Kerry McLaughlin [Tue, 8 Jun 2021 08:16:07 +0000 (09:16 +0100)]
[LoopVectorize] Don't use strict reductions when reordering is allowed
If the `-enable-strict-reductions` flag is set to true, then currently we will
always choose to vectorize the loop with strict in-order reductions. This is
not necessary where we allow the reordering of FP operations, such as
when loop hints are passed via metadata.
This patch moves useOrderedReductions so that we can also check whether
loop hints allow reordering, in which case we should use the default
behaviour of vectorizing with unordered reductions.
Reviewed By: sdesmalen
Differential Revision: https://reviews.llvm.org/D103814
Alex Zinenko [Tue, 8 Jun 2021 09:30:31 +0000 (11:30 +0200)]
[mlir] fix shared-libs build
David Green [Tue, 8 Jun 2021 09:18:58 +0000 (10:18 +0100)]
[DAG] Allow isNullOrNullSplat to see truncated zeroes
This sets the AllowTruncation flag on isConstOrConstSplat in
isNullOrNullSplat, allowing it to see truncated constant zeroes on
architectures such as AArch64, where only a i32.i64 are legal. As a
truncation of 0 is always 0, this should always be valid, allowing some
extra folding to happen including some of the cases from D103755.
Differential Revision: https://reviews.llvm.org/D103756
Martin Storsjö [Mon, 31 May 2021 20:59:56 +0000 (23:59 +0300)]
[clang] Apply MS ABI details on __builtin_ms_va_list on non-windows platforms on x86_64
This fixes inconsistencies in the ms_abi.c testcase.
Also add a couple cases of missing double pointers in the windows part
of the testcase; the outcome of building that testcase on windows hasn't
changed, but the previous form of the test was imprecise (checking
for "%[[STRUCT_FOO]]*" when clang actually generates "%[[STRUCT_FOO]]**"),
which still used to match.
Ideally this would share code with the native Windows case, but
X86_64ABIInfo and WinX86_64ABIInfo aren't superclasses/subclasses of
each other so it's impractical, and the code to share currently only
consists of a couple lines.
Differential Revision: https://reviews.llvm.org/D103837
Alex Zinenko [Mon, 7 Jun 2021 16:33:42 +0000 (18:33 +0200)]
[mlir] support memref of memref in standard-to-llvm conversion
Now that memref supports arbitrary element types, add support for memref of
memref and make sure it is properly converted to the LLVM dialect. The type
support itself avoids adding the interface to the memref type itself similarly
to other built-in types. This allows the shape, and therefore byte size, of the
memref descriptor to remain a lowering aspect that is easier to customize and
evolve as opposed to sanctifying it in the data layout specification for the
memref type itself.
Factor out the code previously in a testing pass to live in a dedicated data
layout analysis and use that analysis in the conversion to compute the
allocation size for memref of memref. Other conversions will be ported
separately.
Depends On D103827
Reviewed By: rriddle
Differential Revision: https://reviews.llvm.org/D103828
Alex Zinenko [Mon, 7 Jun 2021 16:33:29 +0000 (18:33 +0200)]
[mlir] Make MemRef element type extensible
Historically, MemRef only supported a restricted list of element types that
were known to be storable in memory. This is unnecessarily restrictive given
the open nature of MLIR's type system. Allow types to opt into being used as
MemRef elements by implementing a type interface. For now, the interface is
merely a declaration with no methods. Later, methods to query, e.g., the type
size or whether a type can alias elements of another type may be added.
Harden the "standard"-to-LLVM conversion against memrefs with non-builtin
types.
See https://llvm.discourse.group/t/rfc-memref-of-custom-types/3558.
Depends On D103826
Reviewed By: rriddle
Differential Revision: https://reviews.llvm.org/D103827
Alex Zinenko [Mon, 7 Jun 2021 16:33:18 +0000 (18:33 +0200)]
[mlir] fix integer type mismatch in alloc conversion to LLVM
Some places in the alloc-like op conversion use the converted index type
whereas other places use the pointer-sized integer type, which may not be the
same. Consistently use the converted index type, similarly to other address
calculations.
Reviewed By: pifon2a
Differential Revision: https://reviews.llvm.org/D103826
Javier Setoain [Tue, 8 Jun 2021 09:02:19 +0000 (10:02 +0100)]
Revert "[mlir][ArmSVE] Add basic mask generation operations"
This reverts commit
392af6a78bb7dfb87a24ed66db598c1d09ac756b
Lang Hames [Sat, 5 Jun 2021 16:48:29 +0000 (09:48 -0700)]
[JITLink] Clarify LinkGraph::splitBlock contract in comment.
David Spickett [Fri, 4 Jun 2021 15:57:13 +0000 (16:57 +0100)]
[lldb] Set return status to failed when adding a command error
There is a common pattern:
result.AppendError(...);
result.SetStatus(eReturnStatusFailed);
I found that some commands don't actually "fail" but only
print "error: ..." because the second line got missed.
This can cause you to miss a failed command when you're
using the Python interface during testing.
(and produce some confusing script results)
I did not find any place where you would want to add
an error without setting the return status, so just
set eReturnStatusFailed whenever you add an error to
a command result.
This change does not remove any of the now redundant
SetStatus. This should allow us to see if there are any
tests that have commands unexpectedly fail with this change.
(the test suite passes for me but I don't have access to all
the systems we cover so there could be some corner cases)
Some tests that failed on x86 and AArch64 have been modified
to work with the new behaviour.
Differential Revision: https://reviews.llvm.org/D103701
Tomasz Miąsko [Mon, 7 Jun 2021 21:35:50 +0000 (23:35 +0200)]
[Demangle][Rust] Parse const backreferences
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D103848
Tomasz Miąsko [Mon, 7 Jun 2021 21:35:25 +0000 (23:35 +0200)]
[Demangle][Rust] Parse type backreferences
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D103847
Tomasz Miąsko [Mon, 7 Jun 2021 21:34:34 +0000 (23:34 +0200)]
[Demangle][Rust] Parse path backreferences
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D103459
Javier Setoain [Thu, 22 Apr 2021 08:29:02 +0000 (09:29 +0100)]
[mlir][ArmSVE] Add basic mask generation operations
These `arm_sve.cmp` functions are needed to generate scalable vector
masks as long as scalable vectors are not part of the standard types.
Once in standard, these can be removed and `std.cmp` can be used
instead.
Differential Revision: https://reviews.llvm.org/D103473
Denys Petrov [Mon, 7 Jun 2021 12:01:53 +0000 (15:01 +0300)]
[analyzer] [NFC] Implement a wrapper SValBuilder::getCastedMemRegionVal for similar functionality on region cast
Summary: Replaced code on region cast with a function-wrapper SValBuilder::getCastedMemRegionVal. This is a next step of code refining due to suggestions in D103319.
Differential Revision: https://reviews.llvm.org/D103803
Petr Hosek [Wed, 28 Apr 2021 18:23:54 +0000 (11:23 -0700)]
[Driver] Support libc++ in MSVC
This implements support for using libc++ headers and library in the MSVC
toolchain. We only support libc++ that is a part of the toolchain, and
not headers installed elsewhere on the system.
Differential Revision: https://reviews.llvm.org/D101479
Craig Topper [Tue, 8 Jun 2021 05:40:54 +0000 (22:40 -0700)]
[RISCV] Use 0 for Log2SEW for vle1/vse1 intrinsics to enable vsetvli optimization.
Missed in D103299.
Craig Topper [Tue, 8 Jun 2021 04:43:42 +0000 (21:43 -0700)]
[RISCV] Masked compares should use a tail agnostic policy.
Writes of a mask result are always tail agnostic.
Unfortunately, this seems to have made codegen worse. I can only
think this must be because the vsetvli was acting as some sort
of barrier that prevented some code movement in the scheduler.
Reviewed By: arcbbb
Differential Revision: https://reviews.llvm.org/D103331
Craig Topper [Tue, 8 Jun 2021 04:15:18 +0000 (21:15 -0700)]
[RISCV] Use AVL Operand instead of GPR for tied mask pseudo for vwadd.wv and similar.
I mistakenly copied this from an older version of our internal
repo.
Yonghong Song [Mon, 7 Jun 2021 21:54:23 +0000 (14:54 -0700)]
BPF: fix relocation types in lib/Object/RelocationResolver.cpp
Commit
6a2ea84600ba ("BPF: Add more relocation kinds")
added new relocations R_BPF_64_ABS64 and R_BPF_64_ABS32
for normal 64-bit and 32-bit data relocations.
This is to replace some of functionalities with
R_BPF_64_64 and R_BPF_64_32 so that new R_BPF_64_64
and R_BPF_64_32 semantics are for ld_imm64 and
call instructions only.
The BPF support in lib/Object/RelocationResolver.cpp
is used to perform normal data relocations for
the case like DWARFObjInMemory with an object file
(search function getRelocationResolver() in file
DebugInfo/DWARF/DWARFContext.cpp) or llvm-readobj
to dump ".stack_sizes" section data.
In all these casees, normal 64-bit and 32-bit relocations
are performed and such resolution resolution
is exactly what implemented in RelocationResolver.cpp.
But Commit
6a2ea84600ba missed to change
R_BPF_64_64/R_BPF_64_32 to R_BPF_64_ABS64/R_BPF_64_ABS32.
This patch fixed the issue and added a test for it
with llvm-readobj dumping ".stack_sizes" section.
Differential Revision: https://reviews.llvm.org/D103864
Jez Ng [Tue, 8 Jun 2021 03:48:16 +0000 (23:48 -0400)]
[lld-macho] Implement -force_load_swift_libs
It causes libraries whose names start with "swift" to be force-loaded.
Note that unlike the more general `-force_load`, this flag only applies
to libraries specified via LC_LINKER_OPTIONS, and not those passed on
the command-line. This is what ld64 does.
Reviewed By: #lld-macho, thakis
Differential Revision: https://reviews.llvm.org/D103709
Jez Ng [Tue, 8 Jun 2021 03:47:12 +0000 (23:47 -0400)]
[lld-macho] Implement cstring deduplication
Our implementation draws heavily from LLD-ELF's, which in turn delegates
its string deduplication to llvm-mc's StringTableBuilder. The messiness of
this diff is largely due to the fact that we've previously assumed that
all InputSections get concatenated together to form the output. This is
no longer true with CStringInputSections, which split their contents into
StringPieces. StringPieces are much more lightweight than InputSections,
which is important as we create a lot of them. They may also overlap in
the output, which makes it possible for strings to be tail-merged. In
fact, the initial version of this diff implemented tail merging, but
I've dropped it for reasons I'll explain later.
**Alignment Issues**
Mergeable cstring literals are found under the `__TEXT,__cstring`
section. In contrast to ELF, which puts strings that need different
alignments into different sections, clang's Mach-O backend puts them all
in one section. Strings that need to be aligned have the `.p2align`
directive emitted before them, which simply translates into zero padding
in the object file.
I *think* ld64 extracts the desired per-string alignment from this data
by preserving each string's offset from the last section-aligned
address. I'm not entirely certain since it doesn't seem consistent about
doing this; but perhaps this can be chalked up to cases where ld64 has
to deduplicate strings with different offset/alignment combos -- it
seems to pick one of their alignments to preserve. This doesn't seem
correct in general; we can in fact can induce ld64 to produce a crashing
binary just by linking in an additional object file that only contains
cstrings and no code. See PR50563 for details.
Moreover, this scheme seems rather inefficient: since unaligned and
aligned strings are all put in the same section, which has a single
alignment value, it doesn't seem possible to tell whether a given string
doesn't have any alignment requirements. Preserving offset+alignments
for strings that don't need it is wasteful.
In practice, the crashes seen so far seem to stem from x86_64 SIMD
operations on cstrings. X86_64 requires SIMD accesses to be
16-byte-aligned. So for now, I'm thinking of just aligning all strings
to 16 bytes on x86_64. This is indeed wasteful, but implementation-wise
it's simpler than preserving per-string alignment+offsets. It also
avoids the aforementioned crash after deduplication of
differently-aligned strings. Finally, the overhead is not huge: using
16-byte alignment (vs no alignment) is only a 0.5% size overhead when
linking chromium_framework.
With these alignment requirements, it doesn't make sense to attempt tail
merging -- most strings will not be eligible since their overlaps aren't
likely to start at a 16-byte boundary. Tail-merging (with alignment) for
chromium_framework only improves size by 0.3%.
It's worth noting that LLD-ELF only does tail merging at `-O2`. By
default (at `-O1`), it just deduplicates w/o tail merging. @thakis has
also mentioned that they saw it regress compressed size in some cases
and therefore turned it off. `ld64` does not seem to do tail merging at
all.
**Performance Numbers**
CString deduplication reduces chromium_framework from 250MB to 242MB, or
about a 3.2% reduction.
Numbers for linking chromium_framework on my 3.2 GHz 16-Core Intel Xeon W:
N Min Max Median Avg Stddev
x 20 3.91 4.03 3.935 3.95 0.
034641016
+ 20 3.99 4.14 4.015 4.0365 0.0492336
Difference at 95.0% confidence
0.0865 +/- 0.027245
2.18987% +/- 0.689746%
(Student's t, pooled s = 0.0425673)
As expected, cstring merging incurs some non-trivial overhead.
When passing `--no-literal-merge`, it seems that performance is the
same, i.e. the refactoring in this diff didn't cost us.
N Min Max Median Avg Stddev
x 20 3.91 4.03 3.935 3.95 0.
034641016
+ 20 3.89 4.02 3.935 3.9435 0.
043197831
No difference proven at 95.0% confidence
Reviewed By: #lld-macho, gkm
Differential Revision: https://reviews.llvm.org/D102964
Esme-Yi [Tue, 8 Jun 2021 03:00:52 +0000 (03:00 +0000)]
[yaml2obj] Fix buildbot-issue-4886
XCOFFEmitter.cpp:67:16: runtime error: null pointer passed as argument 2,
which is declared to never be null
Carl Ritson [Tue, 8 Jun 2021 02:31:08 +0000 (11:31 +0900)]
[AMDGPU] Allow oversize vaddr in GFX10 MIMG assembly
As a follow up to D103672, we should allow vaddr to be larger than
required when assembling GFX10 MIMG instructions.
Reviewed By: dp
Differential Revision: https://reviews.llvm.org/D103733
Jake.Egan [Tue, 8 Jun 2021 02:36:07 +0000 (22:36 -0400)]
[AIX] Define __STDC_NO_ATOMICS__ and __STDC_NO_THREADS__
Revert/reapply to fix Git authorship metadata
Differential Revision: https://reviews.llvm.org/D103707
Chris Bowler [Tue, 8 Jun 2021 02:34:15 +0000 (22:34 -0400)]
Revert "[AIX] Define __STDC_NO_ATOMICS__ and __STDC_NO_THREADS__ predefined macros"
This reverts commit
e6629be31e67190f0a524f009752d73410894560.
Carl Ritson [Tue, 8 Jun 2021 02:10:53 +0000 (11:10 +0900)]
[AMDGPU] Add v5f32/VReg_160 support for MIMG instructions
Avoid having to round up to v8f32/VReg_256 when only 5 VGPRs are
required for a MIMG address operand.
Maintain _V8 instruction variants of pseudo instructions allowing
assembly prior to GFX10 to work as-is. Currently the validator
can tell for GFX10 what the correct size is, so will disallow
oversize address registers.
Reviewed By: rampitec
Differential Revision: https://reviews.llvm.org/D103672
=Jake Egan [Tue, 8 Jun 2021 01:56:47 +0000 (21:56 -0400)]
[AIX] Define __STDC_NO_ATOMICS__ and __STDC_NO_THREADS__ predefined macros
Differential Revision: https://reviews.llvm.org/D103707
Vitaly Buka [Tue, 8 Jun 2021 01:54:14 +0000 (18:54 -0700)]
[NFC][scudo] Print errno of fork failure
This fork fails sometime on sanitizer-x86_64-linux-qemu bot.
Craig Topper [Mon, 7 Jun 2021 23:35:27 +0000 (16:35 -0700)]
[RISCV] Use bitfields to shrink the size of the vector load/store intrinsics to pseudo instruction lookup tables.