Louis Dionne [Fri, 7 May 2021 17:14:57 +0000 (13:14 -0400)]
[libc++] Use Xcode's CMake if it's present
This resolves issues when the CMake in use on the host is too old to
configure libc++ properly, but Xcode has a sufficiently recent version.
It is technically possible for the reverse issue to happen, where the
Xcode version would be too old and the user-installed version would be
better, however in the context of our build bots, we use AppleClang on
Apple platforms, and the CMake shipped with Xcode should work with the
AppleClang shipped alongside that Xcode.
Differential Revision: https://reviews.llvm.org/D102083
Qiu Chaofan [Sat, 8 May 2021 10:13:05 +0000 (18:13 +0800)]
[VectorCombine] Simplify to scalar store if only one element updated
This patch simplifies load-insertelt-store pattern into
getelementptr-store.
Reviewed By: fhahn
Differential Revision: https://reviews.llvm.org/D98240
Butygin [Sat, 10 Apr 2021 16:38:11 +0000 (19:38 +0300)]
[mlir] Debug print pattern before and after matchAndRewrite call
Motivation: we have passes with lot of rewrites and when one one them segfaults or asserts, it is very hard to find waht exactly pattern failed without debug info.
Differential Revision: https://reviews.llvm.org/D101443
Xiang1 Zhang [Sat, 8 May 2021 05:46:51 +0000 (13:46 +0800)]
[X86] Support AMX fast register allocation
Differential Revision: https://reviews.llvm.org/D100026
Arthur Eubanks [Sat, 8 May 2021 06:18:44 +0000 (23:18 -0700)]
Fix build after
34a8a437b
Xiang1 Zhang [Sat, 8 May 2021 05:43:32 +0000 (13:43 +0800)]
Revert "[X86] Support AMX fast register allocation"
This reverts commit
77e2e5e07d01fe0b83c39d0c527c0d3d2e659146.
Xiang1 Zhang [Fri, 7 May 2021 02:46:52 +0000 (10:46 +0800)]
[X86] Support AMX fast register allocation
Michael Liao [Sat, 8 May 2021 05:09:15 +0000 (01:09 -0400)]
Replace a remaining CRLF with LF. NFC.
Arthur Eubanks [Mon, 3 May 2021 23:09:56 +0000 (16:09 -0700)]
[NewPM] Hide pass manager debug logging behind -debug-pass-manager-verbose
Printing pass manager invocations is fairly verbose and not super
useful.
This allows us to remove DebugLogging from pass managers and PassBuilder
since all logging (aside from analysis managers) goes through
instrumentation now.
This has the downside of never being able to print the top level pass
manager via instrumentation, but that seems like a minor downside.
Reviewed By: ychen
Differential Revision: https://reviews.llvm.org/D101797
RamNalamothu [Sat, 8 May 2021 04:45:49 +0000 (10:15 +0530)]
[DebugInfo] UnwindTable::create() should not add empty rows to CFI unwind table
UnwindTable::parseRows() may return successfully if the CFIProgram has either
no CFI instructions or only DW_CFA_nop instructions and the UnwindRow return
argument will be empty. But currently, the callers are not checking for this case
which is leading to incorrect dumps in the unwind tables in such cases i.e.
CFA=unspecified
Reviewed By: clayborg
Differential Revision: https://reviews.llvm.org/D101892
River Riddle [Sat, 8 May 2021 02:30:25 +0000 (19:30 -0700)]
[mlir] Refactor the representation of function-like argument/result attributes.
The current design uses a unique entry for each argument/result attribute, with the name of the entry being something like "arg0". This provides for a somewhat sparse design, but ends up being much more expensive (from a runtime perspective) in-practice. The design requires building a string every time we lookup the dictionary for a specific arg/result, and also requires N attribute lookups when collecting all of the arg/result attribute dictionaries.
This revision restructures the design to instead have an ArrayAttr that contains all of the attribute dictionaries for arguments and another for results. This design reduces the number of attribute name lookups to 1, and allows for O(1) lookup for individual element dictionaries. The major downside is that we can end up with larger memory usage, as the ArrayAttr contains an entry for each element even if that element has no attributes. If the memory usage becomes too problematic, we can experiment with a more sparse structure that still provides a lot of the wins in this revision.
This dropped the compilation time of a somewhat large TensorFlow model from ~650 seconds to ~400 seconds.
Differential Revision: https://reviews.llvm.org/D102035
Arthur Eubanks [Sat, 8 May 2021 01:11:21 +0000 (18:11 -0700)]
[lit] Bump up the Windows process cap from 32 to 60
At 61 or over, I see messages like
File "...\Python\Python39\lib\multiprocessing\connection.py", line 816, in _exhaustive_wait
res = _winapi.WaitForMultipleObjects(L, False, timeout)
ValueError: need at most 63 handles, got a sequence of length 64
60 seems to work for me.
If this causes issues for anybody else, feel free to revert.
River Riddle [Sat, 8 May 2021 00:55:52 +0000 (17:55 -0700)]
[mlir] Add hover support to mlir-lsp-server
This provides information when the user hovers over a part of the source .mlir file. This revision adds the following hover behavior:
* Operation:
- Shows the generic form.
* Operation Result:
- Shows the parent operation name, result number(s), and type(s).
* Block:
- Shows the parent operation name, block number, predecessors, and successors.
* Block Argument:
- Shows the parent operation name, parent block, argument number, and type.
Differential Revision: https://reviews.llvm.org/D101113
Arthur Eubanks [Sat, 8 May 2021 01:00:11 +0000 (18:00 -0700)]
Revert "lit: revert
134b103fc0f3a995d76398bf4b029d72bebe8162"
This reverts commit
d319005a3746a7661c8c9a3302266b6ff7cf61be.
Causing messages like:
File "...\Python\Python39\lib\multiprocessing\connection.py", line 816, in _exhaustive_wait
res = _winapi.WaitForMultipleObjects(L, False, timeout)
ValueError: need at most 63 handles, got a sequence of length 74
Arthur Eubanks [Sat, 8 May 2021 00:54:32 +0000 (17:54 -0700)]
[gn build] Manually port
5b158093e
thomasraoux [Sat, 8 May 2021 00:10:35 +0000 (17:10 -0700)]
[mlir][vector] Fix warning
Previous change caused another warning in some build configuration:
"default label in switch which covers all enumeration values"
Amara Emerson [Fri, 7 May 2021 00:14:04 +0000 (17:14 -0700)]
[AArch64][GlobalISel] Create a new minimal combiner pass just for -O0.
We never bothered to have a separate set of combines for -O0 in the prelegalizer
before. This results in some minor performance hits for a mode where performance
isn't a concern (although not regressing code size significantly is still preferable).
This also removes the CSE option since we don't need it for -O0.
Through experiments, I've arrived at a set of combines that gets the most code
size improvement at -O0, while reducing the amount of time spent in the combiner
by around 35% give or take.
Differential Revision: https://reviews.llvm.org/D102038
Amara Emerson [Wed, 5 May 2021 18:37:00 +0000 (11:37 -0700)]
[GlobalISel] Don't form zero/sign extending loads for atomics.
For importing patterns, we only support matching G_LOAD, not G_ZEXTLOAD or
G_SEXTLOAD.
Differential Revision: https://reviews.llvm.org/D101932
Weston Carvalho [Thu, 29 Apr 2021 21:30:47 +0000 (14:30 -0700)]
Make `hasTypeLoc` matcher support more node types.
Differential Revision: https://reviews.llvm.org/D101572
Weston Carvalho [Fri, 7 May 2021 23:32:57 +0000 (00:32 +0100)]
NFC: Move TypeList implementation up the file
This will make it possible for more code to use it.
Arthur Eubanks [Fri, 7 May 2021 21:32:40 +0000 (14:32 -0700)]
[NewPM] Move analysis invalidation/clearing logging to instrumentation
We're trying to move DebugLogging into instrumentation, rather than
being part of PassManagers/AnalysisManagers.
Reviewed By: ychen
Differential Revision: https://reviews.llvm.org/D102093
Jessica Paquette [Tue, 20 Apr 2021 23:07:54 +0000 (16:07 -0700)]
[AArch64][GlobalISel] Legalize narrow type G_CTPOPs
Using `clampScalar` here because we ought to mark s128 as custom eventually.
(Right now, it will just fall back.)
With this legalization, we get the same code as SDAG:
https://godbolt.org/z/TneoPKrKG
Differential Revision: https://reviews.llvm.org/D100908
Adrian Prantl [Fri, 7 May 2021 21:44:45 +0000 (14:44 -0700)]
Fix the module-enabled build by removing a redundant type definition.
Petr Hosek [Fri, 7 May 2021 06:05:39 +0000 (23:05 -0700)]
[BareMetal] Ensure that sysroot always comes after library paths
This addresses an issue introduced in D91559. We would invoke the
compiler with -Lpath/to/lib --sysroot=path/to/sysroot where both
locations contain libraries with the same name, but we expect linker
to pick up the library in path/to/lib since that version is more
specialized. This was the case before D91559 where the sysroot path
would be ignored, but after that change linker would now pick up the
library from the sysroot which resulted in unexpected behavior.
The sysroot path should always come after any user provided library
paths, followed by compiler runtime paths. We want for libraries in user
provided library paths to always take precedence over sysroot libraries.
This matches the behavior of other toolchains used with other targets.
Differential Revision: https://reviews.llvm.org/D102049
Nico Weber [Thu, 6 May 2021 18:47:57 +0000 (14:47 -0400)]
[lld/mac] Write every weak symbol only once in the output
Before this, if an inline function was defined in several input files,
lld would write each copy of the inline function the output. With this
patch, it only writes one copy.
Reduces the size of Chromium Framework from 378MB to 345MB (compared
to 290MB linked with ld64, which also does dead-stripping, which we
don't do yet), and makes linking it faster:
N Min Max Median Avg Stddev
x 10 3.9957051 4.3496981 4.1411121 4.156837 0.
10092097
+ 10 3.908154 4.169318 3.9712729 3.9846753 0.
075773012
Difference at 95.0% confidence
-0.172162 +/- 0.083847
-4.14165% +/- 2.01709%
(Student's t, pooled s = 0.0892373)
Implementation-wise, when merging two weak symbols, this sets a
"canOmitFromOutput" on the InputSection belonging to the weak symbol not put in
the symbol table. We then don't write InputSections that have this set, as long
as they are not referenced from other symbols. (This happens e.g. for object
files that don't set .subsections_via_symbols or that use .alt_entry.)
Some restrictions:
- not yet done for bitcode inputs
- no "comdat" handling (`kindNoneGroupSubordinate*` in ld64) --
Frame Descriptor Entries (FDEs), Language Specific Data Areas (LSDAs)
(that is, catch block unwind information) and Personality Routines
associated with weak functions still not stripped. This is wasteful,
but harmless.
- However, this does strip weaks from __unwind_info (which is needed for
correctness and not just for size)
- This nopes out on InputSections that are referenced form more than
one symbol (eg from .alt_entry) for now
Things that work based on symbols Just Work:
- map files (change in MapFile.cpp is no-op and not needed; I just
found it a bit more explicit)
- exports
Things that work with inputSections need to explicitly check if
an inputSection is written (e.g. unwind info).
This patch is useful in itself, but it's also likely also a useful foundation
for dead_strip.
I used to have a "canoncialRepresentative" pointer on InputSection instead of
just the bool, which would be handy for ICF too. But I ended up not needing it
for this patch, so I removed that again for now.
Differential Revision: https://reviews.llvm.org/D102076
thomasraoux [Fri, 7 May 2021 20:57:34 +0000 (13:57 -0700)]
[mlir] Missed clang-format
thomasraoux [Fri, 7 May 2021 20:44:33 +0000 (13:44 -0700)]
[mlir][vector] Extend pattern to trim lead unit dimension to Splat Op
Differential Revision: https://reviews.llvm.org/D102091
Petr Hosek [Fri, 7 May 2021 20:38:04 +0000 (13:38 -0700)]
Revert "[BareMetal] Ensure that sysroot always comes after library paths"
This reverts commit
6b00b34b8a05896f79b18a1963811299b83d5b21.
Florian Hahn [Fri, 7 May 2021 20:30:54 +0000 (21:30 +0100)]
[LV] Remove reference of PHI from comment, they are not recorded (NFC).
The comment incorrectly states that the PHI is recorded. That's not
accurate, only the recipe for the incoming value is recorded.
Suggested post-commit for
4ba8720f8844.
Andrea Di Biagio [Fri, 7 May 2021 19:20:03 +0000 (20:20 +0100)]
[MCA][RegisterFile] Fix register class check for move elimination (PR50265)
The register file should always check if the destination register is from a
register class that allows move elimination.
Before this change, the check on the register class was only performed in a few
very specific cases. However, it should have always been performed.
This patch fixes the issue.
Note that none of the upstream scheduling models is currently affected by this
bug, so there is no test for it. The issue was found by Roman while working on
the znver3 model. I was able to reproduce the issue locally by tweaking the
btver2 model. I then verified that this patch fixes the issue.
Olivier Goffart [Fri, 7 May 2021 20:23:53 +0000 (13:23 -0700)]
[SEH] Fix regression with SEH in noexpect functions
Commit
5baea0560160a693b19022c5d0ba637b6b46b2d8 set the CurCodeDecl
because it was needed to pass the assert in CodeGenFunction::EmitLValueForLambdaField,
But this was not right to do as CodeGenFunction::FinishFunction passes it to EmitEndEHSpec
and cause corruption of the EHStack.
Revert the part of the commit that changes the CurCodeDecl, and instead
adjust the assert to check for a null CurCodeDecl.
Differential Revision: https://reviews.llvm.org/D102027
Florian Hahn [Fri, 7 May 2021 20:05:58 +0000 (21:05 +0100)]
[LV] Assert if trying to sink replicate region into another region (NFC)
Currently sinking a replicate region into another replicate region is
not supported. Add an assert, to make the problem more obvious, should
it occur.
Discussed post-commit for
ccebf7a1096a.
Florian Hahn [Fri, 7 May 2021 19:21:36 +0000 (20:21 +0100)]
[LV] Rename Region to TargetRegion, similar to SinkRegion (NFC).
Adjust the name to make it clearer this is the region containing the
target recipe, similar to SinkRegion below.
Suggested post-commit for
ccebf7a1096a.
peter klausler [Thu, 6 May 2021 20:50:12 +0000 (13:50 -0700)]
[flang] Implement NORM2 in the runtime
Implement the reduction transformational intrinsic function NORM2 in
the runtime, using infrastructure already in place for MAXVAL & al.
Differential Revision: https://reviews.llvm.org/D102024
Petr Hosek [Fri, 7 May 2021 06:05:39 +0000 (23:05 -0700)]
[BareMetal] Ensure that sysroot always comes after library paths
This addresses an issue introduced in D91559. We would invoke the
compiler with -Lpath/to/lib --sysroot=path/to/sysroot where both
locations contain libraries with the same name, but we expect linker
to pick up the library in path/to/lib since that version is more
specialized. This was the case before D91559 where the sysroot path
would be ignored, but after that change linker would now pick up the
library from the sysroot which resulted in unexpected behavior.
The sysroot path should always come after any user provided library
paths, followed by compiler runtime paths. We want for libraries in user
provided library paths to always take precedence over sysroot libraries.
This matches the behavior of other toolchains used with other targets.
Differential Revision: https://reviews.llvm.org/D102049
Hsiangkai Wang [Fri, 7 May 2021 07:18:11 +0000 (15:18 +0800)]
[RISCV] Consider scalar types for required extensions.
We have vector operations on double vector and float scalar. For
example, vfwadd.wf is such a instruction.
vfloat64m1_t vfwadd_wf(vfloat64m1_t op0, float op1, size_t op2);
We should specify F and D extensions for it.
Differential Revision: https://reviews.llvm.org/D102051
Vyacheslav Zakharin [Fri, 7 May 2021 19:42:04 +0000 (12:42 -0700)]
An attempt to abandon omptarget out-of-tree builds.
I want to start using LLVM component libraries in libomptarget
to stop duplicating implementations already available in LLVM
(e.g. LLVMObject, LLVMSupport, etc.). Without relying on LLVM
in all libomptarget builds one has to provide fallback implementation
for each used LLVM feature.
This is an attempt to stop supporting out-of-llvm-tree builds of libomptarget.
I understand that I may need to revert this,
if this affects downstream projects in a bad way.
Differential Revision: https://reviews.llvm.org/D101509
Alexander Belyaev [Fri, 7 May 2021 19:20:55 +0000 (21:20 +0200)]
[mlir] Add a pattern to bufferize std.index_cast.
Differential Revision: https://reviews.llvm.org/D102088
Alexander Belyaev [Fri, 7 May 2021 19:21:54 +0000 (21:21 +0200)]
[mlir] Add a pattern to bufferize linalg.tensor_reshape.
Differential Revision: https://reviews.llvm.org/D102089
Emilio Cota [Fri, 7 May 2021 19:23:01 +0000 (19:23 +0000)]
[mlir][docs] remove stale statement about index type in vectors
b614ada0e8 ("[mlir] add support for index type in vectors.") removed
this limitation.
Differential Revision: https://reviews.llvm.org/D102081
Arthur Eubanks [Fri, 7 May 2021 19:05:16 +0000 (12:05 -0700)]
Revert "[DebugInfo] Fix updateDbgUsersToReg to support DBG_VALUE_LIST"
This reverts commit
0791f968fee259e5c34523167bd58179b8b081c2.
Causing crashes: https://crbug.com/1206764
Florian Hahn [Fri, 7 May 2021 18:39:05 +0000 (19:39 +0100)]
[SCEV] By more careful when traversing phis in isImpliedViaMerge.
I think currently isImpliedViaMerge can incorrectly return true for phis
in a loop/cycle, if the found condition involves the previous value of
Consider the case in exit_cond_depends_on_inner_loop.
At some point, we call (modulo simplifications)
isImpliedViaMerge(<=, %x.lcssa, -1, %call, -1).
The existing code tries to prove IncV <= -1 for all incoming values
InvV using the found condition (%call <= -1). At the moment this succeeds,
but only because it does not compare the same runtime value. The found
condition checks the value of the last iteration, but the incoming value
is from the *previous* iteration.
Hence we incorrectly determine that the *previous* value was <= -1,
which may not be true.
I think we need to be more careful when looking at the incoming values
here. In particular, we need to rule out that a found condition refers to
any value that may refer to one of the previous iterations. I'm not sure
there's a reliable way to do so (that also works of irreducible control
flow).
So for now this patch adds an additional requirement that the incoming
value must properly dominate the phi block. This should ensure the
values do not change in a cycle. I am not entirely sure if will catch
all cases and I appreciate a through second look in that regard.
Alternatively we could also unconditionally bail out in this case,
instead of checking the incoming values
Reviewed By: nikic
Differential Revision: https://reviews.llvm.org/D101829
Thomas Lively [Fri, 7 May 2021 18:50:19 +0000 (11:50 -0700)]
[WebAssembly] Use functions instead of macros for const SIMD intrinsics
To improve hygiene, consistency, and usability, it would be good to replace all
the macro intrinsics in wasm_simd128.h with functions. The reason for using
macros in the first place was to enforce the use of constants for some arguments
using `_Static_assert` with `__builtin_constant_p`. This commit switches to
using functions and uses the `__diagnose_if__` attribute rather than
`_Static_assert` to enforce constantness.
The remaining macro intrinsics cannot be made into functions until the builtin
functions they are implemented with can be replaced with normal code patterns
because the builtin functions themselves require that their arguments are
constants.
This commit also fixes a bug with the const_splat intrinsics in which the f32x4
and f64x2 variants were incorrectly producing integer vectors.
Differential Revision: https://reviews.llvm.org/D102018
Fangrui Song [Fri, 7 May 2021 18:42:16 +0000 (11:42 -0700)]
[unittest] Fix -Wunused-variable after D94717
Krzysztof Parzyszek [Fri, 7 May 2021 17:52:20 +0000 (12:52 -0500)]
Allow empty value list in propagateMetadata(Inst, ArrayOf...)
This will allow writing
propagateMetadata(Inst, collectInterestingValues(...))
without concern about empty lists. In case of an empty list,
Inst is returned without any changes.
Fangrui Song [Fri, 7 May 2021 18:15:43 +0000 (11:15 -0700)]
Internalize some cl::opt global variables or move them under namespace llvm
Louis Dionne [Fri, 7 May 2021 17:57:07 +0000 (13:57 -0400)]
[libc++][ci] Run longer CI jobs first
Jobs that test with a more recent standard version run more tests, so
they take longer. We'll decrease the average latency by running them
first instead of last.
Saleem Abdulrasool [Fri, 7 May 2021 17:18:28 +0000 (10:18 -0700)]
lit: revert
134b103fc0f3a995d76398bf4b029d72bebe8162
Revert the 32-process cap on Windows. When testing with Swift, we found
that there was a time reduction for testing with the higher load. This
should hopefully not matter much in practice. In the case that the
original problem with python remains with a high subprocess count, we
can easily revert this change.
Roman Lebedev [Fri, 7 May 2021 17:05:30 +0000 (20:05 +0300)]
[X86] AMD Zen 3: mark XMM/YMM (but not MMX!) reg moves as eliminatible in RegisterFile
Roman Lebedev [Fri, 7 May 2021 16:36:37 +0000 (19:36 +0300)]
[X86] AMD Zen 3: MOVSX32rr32 is a zero-cycle move
It measures as such, and the reference docs agree.
I can't easily add a MCA test, because there's no mnemonic for it,
it can only be disassembled or created as a MCInst.
Fangrui Song [Fri, 7 May 2021 16:44:26 +0000 (09:44 -0700)]
[AArch64][ELF] Prefer to lower MC_GlobalAddress operands to .Lfoo$local
Similar to X86 D73230 &
46788a21f9152be3950e57dc526454655682bdd4
With this change, we can set dso_local in clang's -fpic -fno-semantic-interposition mode,
for default visibility external linkage non-ifunc-non-COMDAT definitions.
For such dso_local definitions, variable access/taking the address of a
function/calling a function will go through a local alias to avoid GOT/PLT.
Note: the 'S' inline assembly constraint refers to an absolute symbolic address
or a label reference (D46745).
Differential Revision: https://reviews.llvm.org/D101872
Matt Morehouse [Fri, 7 May 2021 16:11:45 +0000 (09:11 -0700)]
[libFuzzer] Fix stack-overflow-with-asan.test.
Fix function return type and remove check for SUMMARY, since it doesn't
seem to be output in Windows.
Whitney Tsang [Fri, 7 May 2021 15:36:55 +0000 (15:36 +0000)]
[LoopNest] Consider loop nest with inner loop guard using outer loop
induction variable to be perfect
This patch allow more conditional branches to be considered as loop
guard, and so more loop nests can be considered perfect.
Reviewed By: bmahjour, sidbav
Differential Revision: https://reviews.llvm.org/D94717
Simon Pilgrim [Fri, 7 May 2021 15:39:11 +0000 (16:39 +0100)]
[X86] combineXor - limit fold to non-opaque constants (PR50254)
Ensure we don't try to fold when one might be an opaque constant - the constant fold will fail and then the reverse fold will happen in DAGCombine.....
Roman Lebedev [Fri, 7 May 2021 15:22:01 +0000 (18:22 +0300)]
[X86] AMD Zen 3: _REV variants of zero-cycles moves are also zero-cycles (PR50261)
Sometimes disassembler picks _REV variants of instructions
over the plain ones, which in this case exposed an issue
that the _REV variants aren't being modelled as optimizable moves.
Roman Lebedev [Fri, 7 May 2021 15:09:18 +0000 (18:09 +0300)]
[NFC][X86][MCA] AMD Zen3: add test for zero-cycle X87 move
Sebastian Poeplau [Fri, 7 May 2021 15:00:33 +0000 (08:00 -0700)]
[libFuzzer] Fix stack overflow detection
Address sanitizer can detect stack exhaustion via its SEGV handler, which is
executed on a separate stack using the sigaltstack mechanism. When libFuzzer is
used with address sanitizer, it installs its own signal handlers which defer to
those put in place by the sanitizer before performing additional actions. In the
particular case of a stack overflow, the current setup fails because libFuzzer
doesn't preserve the flag for executing the signal handler on a separate stack:
when we run out of stack space, the operating system can't run the SEGV handler,
so address sanitizer never reports the issue. See the included test for an
example.
This commit fixes the issue by making libFuzzer preserve the SA_ONSTACK flag
when installing its signal handlers; the dedicated signal-handler stack set up
by the sanitizer runtime appears to be large enough to support the additional
frames from the fuzzer.
Reviewed By: morehouse
Differential Revision: https://reviews.llvm.org/D101824
thomasraoux [Thu, 6 May 2021 23:37:47 +0000 (16:37 -0700)]
[mlir][vector] add pattern to cast away leading unit dim for elementwise op
Differential Revision: https://reviews.llvm.org/D102034
thomasraoux [Thu, 6 May 2021 23:41:43 +0000 (16:41 -0700)]
[mlir][spirv] add support lowering of extract_slice to scalar type
Differential Revision: https://reviews.llvm.org/D102041
Joseph Tremoulet [Fri, 7 May 2021 14:48:18 +0000 (07:48 -0700)]
BasicAA: Recognize inttoptr as isEscapeSource
Pointers escape when converted to integers, so a pointer produced by
converting an integer to a pointer must not be a local non-escaping
object.
Reviewed By: nikic, nlopes, aqjune
Differential Revision: https://reviews.llvm.org/D101541
Sanjay Patel [Fri, 7 May 2021 14:43:47 +0000 (10:43 -0400)]
[AArch64] add test for missed vectorization; NFC
This is a reduction of the example in:
https://llvm.org/PR50256
Joseph Huber [Thu, 6 May 2021 16:42:55 +0000 (12:42 -0400)]
[libomptarget] Add support for target memory allocators to cuda RTL
Summary:
The allocator interface added in D97883 allows the RTL to allocate shared and
host-pinned memory from the cuda plugin. This patch adds support for these to
the runtime.
Reviewed By: grokos
Differential Revision: https://reviews.llvm.org/D102000
Tobias Gysi [Fri, 7 May 2021 14:17:06 +0000 (14:17 +0000)]
[mlir][linalg] Remove redundant indexOp builder.
Remove the builder signature taking a signed dimension identifier.
Reviewed By: ergawy
Differential Revision: https://reviews.llvm.org/D102055
Tres Popp [Tue, 20 Apr 2021 08:36:48 +0000 (10:36 +0200)]
[mlir] Rename BufferAliasAnalysis to BufferViewFlowAnalysis
This it to make more clear the difference between this and
an AliasAnalysis.
For example, given a sequence of subviews that create values
A -> B -> C -> d:
BufferViewFlowAnalysis::resolve(B) => {B, C, D}
AliasAnalysis::resolve(B) => {A, B, C, D}
Differential Revision: https://reviews.llvm.org/D100838
Ahsan Saghir [Tue, 4 May 2021 13:57:27 +0000 (08:57 -0500)]
[PowerPC] Provide MMA builtins for compatibility
Vector pair intrinsics and builtins were renamed in
https://reviews.llvm.org/D91974 to replace the _mma_ prefix by _vsx_.
However, some projects used the _mma_ version, so this patch adds
these intrinsics to provide compatibility.
Fixes Bugzilla: https://bugs.llvm.org/show_bug.cgi?id=50159
Reviewed By: nemanjai, amyk
Differential Revision: https://reviews.llvm.org/D100482
Roman Lebedev [Fri, 7 May 2021 13:45:17 +0000 (16:45 +0300)]
[NFC][X86][MCA] AMD Zen3 Decrease iteration count in reg-move-elimination tests
Drop it just enough so it still produces the right IPC.
Roman Lebedev [Fri, 7 May 2021 13:41:46 +0000 (16:41 +0300)]
[X86] AMD Zen 3: throughput for renameable XMM/YMM moves is 6
They are resolved at the register rename stage without
using any execution units.
Roman Lebedev [Fri, 7 May 2021 13:28:01 +0000 (16:28 +0300)]
[X86] AMD Zen 3: AVX YMM moves are zero-cycle
I've verified this with llvm-exegesis.
This is not limited to zero registers.
Roman Lebedev [Fri, 7 May 2021 13:23:38 +0000 (16:23 +0300)]
[X86] AMD Zen 3: AVX XMM moves are zero-cycle
I've verified this with llvm-exegesis.
This is not limited to zero registers.
Roman Lebedev [Fri, 7 May 2021 13:15:43 +0000 (16:15 +0300)]
[X86] AMD Zen 3: SSE XMM moves are zero-cycle
I've verified this with llvm-exegesis.
This is not limited to zero registers.
Refs:
AMD SOG 19h, 2.9.4 Zero Cycle Move
The processor is able to execute certain register to register
mov operations with zero cycle delay.
Agner,
22.13 Instructions with no latency
Register-to-register move instructions are resolved at
the register rename stage without using any execution units.
These instructions have zero latency. It is possible to do six such
register renamings per clock cycle, and it is even possible to
rename the same register multiple times in one clock cycle.
Roman Lebedev [Fri, 7 May 2021 13:15:35 +0000 (16:15 +0300)]
[NFC][X86][MCA] AMD Zen 3: Add tests for renameable AVX YMM moves
Roman Lebedev [Fri, 7 May 2021 13:15:17 +0000 (16:15 +0300)]
[NFC][X86][MCA] AMD Zen 3: Add tests for renameable AVX XMM moves
Roman Lebedev [Fri, 7 May 2021 13:04:23 +0000 (16:04 +0300)]
[NFC][X86][MCA] AMD Zen 3: Add tests for renameable SSE XMM moves
Roman Lebedev [Fri, 7 May 2021 12:11:14 +0000 (15:11 +0300)]
[X86] AMD Zen 3: throughput for renameable GPR moves is 6
They are resolved at the register rename stage without
using any execution units.
Roman Lebedev [Fri, 7 May 2021 12:43:32 +0000 (15:43 +0300)]
[NFC][X86] AMD Zen 3: move sched classes for renameables moves togeter
Roman Lebedev [Fri, 7 May 2021 12:11:01 +0000 (15:11 +0300)]
[NFC][X86][MCA] Increase iteration count in reg move elimination tests
So the IPC actually stabilizes at 6.
Arthur O'Dwyer [Thu, 6 May 2021 16:18:09 +0000 (12:18 -0400)]
[libc++] [test] Test that unordered_*::swap/move/assign does not invalidate iterators.
And remove the dedicated debug-iterator tests; we want to test this in all modes.
We have a CI step for testing the whole test suite with `--debug_level=1` now.
Part of https://reviews.llvm.org/D102003
Arthur O'Dwyer [Thu, 6 May 2021 15:53:10 +0000 (11:53 -0400)]
[libc++] [test] Simplify arithmetic in list.special/swap.pass.cpp. NFCI.
Part of https://reviews.llvm.org/D102003
Arthur O'Dwyer [Thu, 6 May 2021 15:42:25 +0000 (11:42 -0400)]
[libc++] [test] Test that list::swap/move/move-assign does not invalidate iterators.
And remove the dedicated debug-iterator test; we want to test this in all modes.
We have a CI step for testing the whole test suite with `--debug_level=1` now.
Part of https://reviews.llvm.org/D102003
Stephen Tozer [Fri, 7 May 2021 12:53:09 +0000 (13:53 +0100)]
Reapply "[DebugInfo] Drop DBG_VALUE_LISTs with an excessive number of debug operands"
Reapply
b623df3c, which was reverted while reverting a different patch
with a breaking change. There are no underlying issues with this patch,
so no changes have been made to the original patch.
This reverts commit
b11e4c990771541e440861f017afea7b4ba162f4.
Simon Pilgrim [Fri, 7 May 2021 13:48:10 +0000 (14:48 +0100)]
[CodeGen] Ensure UserValue::getDebugLoc() and UserLabel::getDebugLoc() consistently return a const reference NFCI.
Avoids a lot of unnecessary tracking increments/decrements of the underlying TrackingMDNodeRef.
Simon Pilgrim [Fri, 7 May 2021 12:43:10 +0000 (13:43 +0100)]
[DAG] Ensure all SD classes consistently return a const reference with getDebugLoc(). NFCI.
Avoids a lot of unnecessary tracking increments/decrements of the underlying TrackingMDNodeRef.
Benjamin Kramer [Fri, 7 May 2021 13:15:52 +0000 (15:15 +0200)]
Retire TargetRegisterInfo::getSpillAlignment
getSpillAlign does the same thing.
Sebastian Neubauer [Mon, 3 May 2021 08:14:12 +0000 (10:14 +0200)]
[AMDGPU] Restrict immediate scratch offsets
gfx9 does not work with negative offsets, gfx10 works only with
aligned negative offsets, but not with unaligned negative offsets.
This is slightly more conservative than needed, gfx9 does support
negative offsets when a VGPR address is used and gfx10 supports
negative, unaligned offsets when an SGPR address is used, but we
do not make use of that with this patch.
Differential Revision: https://reviews.llvm.org/D101292
David Stuttard [Mon, 24 Feb 2020 21:19:15 +0000 (21:19 +0000)]
AMDGPU: Correct const_index_stride for wave 32 for PAL ABI
Retrying after revert and fix (removed implicit def flag from operand). Now
passes with expensive_checks enabled.
Since there is a single scratch resource descriptor for all shaders, if there is
a wave32 and a wave64 shader (for instance for VsFs pairs)
then the const_index_stride will be incorrect for wave32 shaders.
Differential Revision: https://reviews.llvm.org/D101830
Change-Id: Ie3b8b2921237968caca91527dd0c97b1b0cc0360
Stephen Tozer [Fri, 7 May 2021 12:36:31 +0000 (13:36 +0100)]
Fix: [DebugInfo] Fix crash when emitting an invalidated SDDbgValue
This patch is a fix for revision
ce0c1f3c, which caused test failures on
bots without x86 as a registered target. This patch moves the test added
in the prior patch to the x86 folder, so that it only runs on bots with
the correct target available.
Malhar Jajoo [Thu, 6 May 2021 23:29:06 +0000 (00:29 +0100)]
[ARM] Transforming memset to Tail predicated Loop
This patch converts llvm.memset intrinsic into Tail Predicated
Hardware loops for a target that supports the Arm M-profile
Vector Extension (MVE).
The llvm.memset is converted to a TP loop for both
constant and non-constant input sizes (of llvm.memset).
Reviewed By: dmgreen
Differential Revision: https://reviews.llvm.org/D100435
Anastasia Stulova [Fri, 7 May 2021 11:15:51 +0000 (12:15 +0100)]
[OpenCL] Fix optional image types.
This change allows the use of identifiers for image types
from `cl_khr_gl_msaa_sharing` freely in the kernel code if
the extension is not supported since they are not in the
list of the reserved identifiers.
This change also removed the need for pragma for the types
in the extensions since the spec does not require the pragma
uses.
Differential Revision: https://reviews.llvm.org/D100983
Joachim Meyer [Thu, 6 May 2021 20:26:19 +0000 (22:26 +0200)]
[NFC] Correctly assert the indents for printEnumValHelpStr.
Only verify that there's no negative indent.
Noted by @chapuni in https://reviews.llvm.org/D93494.
Reviewed By: chapuni
Differential Revision: https://reviews.llvm.org/D102021
Stephen Tozer [Thu, 29 Apr 2021 15:36:05 +0000 (16:36 +0100)]
[DebugInfo] Fix crash when emitting an invalidated SDDbgValue
This patch fixes a crash in the compiler that occurs when certain
invalidated SDDbgValues are emitted. The cause of this was that we would
attempt to check the liveness of the debug value's operands, which
triggers an assert if any of those operands are invalid. This patch
changes this check such that it only occurs if the SDDbgValue is valid;
if not, the check is irrelevant anyway, so can be safely ignored.
Differential Revision: https://reviews.llvm.org/D101540
Simon Pilgrim [Fri, 7 May 2021 12:12:16 +0000 (13:12 +0100)]
[DAG] Add a generic expansion for SHIFT_PARTS opcodes using funnel shifts
Based off a discussion on D89281 - where the AARCH64 implementations were being replaced to use funnel shifts.
Any target that has efficient funnel shift lowering can handle the shift parts expansion using the same expansion, avoiding a lot of duplication.
I've generalized the X86 implementation and moved it to TargetLowering - so far I've found that AARCH64 and AMDGPU benefit, but many other targets (ARM, PowerPC + RISCV in particular) could easily use this with a few minor improvements to their funnel shift lowering (or the folding of their target ops that funnel shifts lower to).
NOTE: I'm trying to avoid adding full SHIFT_PARTS legalizer handling as I think it might actually be possible to remove these opcodes in the medium-term and use funnel shift / libcall expansion directly.
Differential Revision: https://reviews.llvm.org/D101987
David Stuttard [Fri, 7 May 2021 11:49:17 +0000 (12:49 +0100)]
Revert "AMDGPU: Correct const_index_stride for wave 32 for PAL ABI"
This reverts commit
442de0c1adf36bfddb5fb66b442bba8999fa733b.
Simon Pilgrim [Fri, 7 May 2021 11:31:05 +0000 (12:31 +0100)]
[SLP] Regenerate tests to reduce diff in D98714. NFCI.
Simon Pilgrim [Thu, 6 May 2021 17:57:19 +0000 (18:57 +0100)]
[X86] Ensure we pass DebugLoc by const reference where possible. NFCI.
Avoids a lot of unnecessary tracking increments/decrements of the underlying TrackingMDNodeRef
Ole Strohm [Fri, 7 May 2021 11:30:31 +0000 (12:30 +0100)]
[NFC] (test commit) Changed example invocation of C++ for OpenCL
David Stuttard [Mon, 24 Feb 2020 21:19:15 +0000 (21:19 +0000)]
AMDGPU: Correct const_index_stride for wave 32 for PAL ABI
Since there is a single scratch resource descriptor for all shaders, if there is
a wave32 and a wave64 shader (for instance for VsFs pairs)
then the const_index_stride will be incorrect for wave32 shaders.
Differential Revision: https://reviews.llvm.org/D101830
Change-Id: Id8de5566b0d1a07a814e2e7db016df9d20bf6d2c
Roman Lebedev [Fri, 7 May 2021 10:43:46 +0000 (13:43 +0300)]
[NFC][X86][MCA] AMD Zen 3: add tests with non-eliminatible MMX moves
In Zen3, MMX moves are *not* eliminated,
i've verified this with llvm-exegesis.
Roman Lebedev [Fri, 7 May 2021 10:02:14 +0000 (13:02 +0300)]
[X86] AMD Zen 3: 32/64 -bit GPR register moves are zero-cycle
I've verified this with llvm-exegesis.
This is not limited to zero registers.
Refs:
AMD SOG 19h, 2.9.4 Zero Cycle Move
The processor is able to execute certain register to register
mov operations with zero cycle delay.
Agner,
22.13 Instructions with no latency
Register-to-register move instructions are resolved at
the register rename stage without using any execution units.
These instructions have zero latency. It is possible to do six such
register renamings per clock cycle, and it is even possible to
rename the same register multiple times in one clock cycle.
Roman Lebedev [Fri, 7 May 2021 10:02:07 +0000 (13:02 +0300)]
[NFC][X86][MCA] AMD Zen 3: add tests with eliminatible GPR moves
Stephen Tozer [Thu, 29 Apr 2021 15:04:24 +0000 (16:04 +0100)]
[DebugInfo] Fix updateDbgUsersToReg to support DBG_VALUE_LIST
This patch modifies updateDbgUsersToReg to properly handle
DBG_VALUE_LIST instructions, by replacing the hard-coded operand indices
(i.e. getOperand(0)) with the more general getDebugOperandsForReg(), and
updating the register for all matching operands.
Differential Revision: https://reviews.llvm.org/D101523