Eli Friedman [Wed, 23 Jun 2021 19:46:57 +0000 (12:46 -0700)]
[ScalarEvolution] Clarify implementation of getPointerBase().
getPointerBase should only be looking through Add and AddRec
expressions; other expressions either aren't pointers, or can't be
looked through.
Technically, this is a functional change. For a multiply or min/max
expression, if they have exactly one pointer operand, and that operand
is the first operand, the behavior here changes. Similarly, if an AddRec
has a pointer-type step, the behavior changes. But that shouldn't be
happening in practice, and we plan to make such expressions illegal.
Eli Friedman [Wed, 23 Jun 2021 19:42:47 +0000 (12:42 -0700)]
[NFC][ScalarEvolution] Fix SCEVNAryExpr::getType().
SCEVNAryExpr::getType() could return the wrong type for a SCEVAddExpr.
Remove it, and add getType() methods to the relevant subclasses.
NFC because nothing uses it directly, as far as I know; this is just
future-proofing.
Andrew Litteken [Mon, 7 Jun 2021 15:57:39 +0000 (10:57 -0500)]
[IRSim] Adding basic implementation of llvm-sim.
This is a similarity visualization tool that accepts a Module and
passes it to the IRSimilarityIdentifier. The resulting SimilarityGroups
are output in a JSON file.
Tests are found in test/tools/llvm-sim and check for the file not found,
a bad module, and that the JSON is created correctly.
Reviewers: paquette, jroelofs, MaskRay
Recommit of:
15645d044bcfe2a0f63156048b302f997a717688 to fix linking
errors and GN build system.
Differential Revision: https://reviews.llvm.org/D86974
Stanislav Mekhanoshin [Wed, 23 Jun 2021 17:21:40 +0000 (10:21 -0700)]
[AMDGPU] Check for pointer operand while refining LDS align
Also skips the propagation if alignment is 1.
Differential Revision: https://reviews.llvm.org/D104796
pooja2299 [Sun, 13 Jun 2021 19:49:54 +0000 (01:19 +0530)]
[docs][GISel]Added GISel documentation link
Added the GISel docs link here - https://llvm.org/docs/CodeGenerator.html#instruction-selection-section
Differential Revision: https://reviews.llvm.org/D104204
Duncan P. N. Exon Smith [Wed, 23 Jun 2021 18:25:04 +0000 (11:25 -0700)]
IR: Fix use-list-order round-tripping for call and invoke
Fix the use-list-order for call and invoke instructions by setting the
operands in order of their index. This matches the use-list-order
prediction. Note that the verifier precludes sharing operands in callbr
(so there was no bug to fix), but that code was updated for consistency.
Bug was found during review of https://reviews.llvm.org/D104740.
Differential Revision: https://reviews.llvm.org/D104805
Jian Cai [Wed, 23 Jun 2021 19:00:58 +0000 (12:00 -0700)]
Reland "[AArch64] handle -Wa,-march="
This reverts commit
fd11a26d368c5a909fb88548fef2cee7a6c2c931, which was
reverted by
9145a3d4ab7eb05d9fb113b5392e8961df629b88 due to a test
failure on aarch64 backend, e.g.
https://lab.llvm.org/buildbot/#/builders/43/builds/7031. This patch
fixed the test failure.
Reviewed By: DavidSpickett, nickdesaulniers
Differential Revision: https://reviews.llvm.org/D103184
Adrian Prantl [Wed, 23 Jun 2021 18:59:58 +0000 (11:59 -0700)]
Move dwarfdump-invalid.test into the tools/llvm-dwarfdump directory.
Nikita Popov [Wed, 23 Jun 2021 18:56:55 +0000 (20:56 +0200)]
[Constants] Handle addrspacecast with opaque pointer type
This is the same change as D104668, but for constant expression
addrspacecasts.
Adrian Prantl [Wed, 23 Jun 2021 18:50:26 +0000 (11:50 -0700)]
Update test after https://reviews.llvm.org/D104483
Leonard Chan [Fri, 18 Jun 2021 18:10:38 +0000 (11:10 -0700)]
[compiler-rt][hwasan] Add InitState options to thread initialization
Similar to InitOptions in asan, we can use this optional struct for
initializing some members thread objects before they are created. On
linux, this is unused and can remain undefined. On fuchsia, this will
just be the stack bounds.
Differential Revision: https://reviews.llvm.org/D104553
Cyndy Ishida [Wed, 23 Jun 2021 18:39:35 +0000 (11:39 -0700)]
[llvm-tapi-diff] Wrap empty string around StringLiteral NFC
This prevents invalid implicit conversation which caused buildbot
failure.
Nikita Popov [Tue, 22 Jun 2021 20:29:05 +0000 (22:29 +0200)]
[InstCombine] Use getFunctionType()
Avoid fetching pointer element type...
Nico Weber [Wed, 23 Jun 2021 18:25:08 +0000 (14:25 -0400)]
[lld/mac] Don't crash on absolute symbols in unwind info generation
Fixes a regression from
d6565a2dbcbe and PR50820.
Nikita Popov [Tue, 22 Jun 2021 20:10:51 +0000 (22:10 +0200)]
[OpaquePtr] Support invoke instruction
With call support in place, this is only a matter of relaxing a
bitcode reader assertion.
Cyndy Ishida [Wed, 23 Jun 2021 15:55:39 +0000 (08:55 -0700)]
[TextAPI] add symbol name prefixes to central location, NFC
These prefixes are used for printing the symbols coming from tbd files
and they were redundant across locations
River Riddle [Wed, 23 Jun 2021 18:18:38 +0000 (18:18 +0000)]
Fix flang build after D104167
Nikita Popov [Tue, 22 Jun 2021 20:00:40 +0000 (22:00 +0200)]
[OpaquePtr] Support call instruction
Add support for call of opaque pointer, currently only possible for
indirect calls.
This requires a bit of special casing in LLParser, as calls do not
specify the callee operand type explicitly.
Differential Revision: https://reviews.llvm.org/D104740
Sami Tolvanen [Wed, 23 Jun 2021 17:09:21 +0000 (10:09 -0700)]
ThinLTO: Fix inline assembly references to static functions with CFI
Create an internal alias with the original name for static functions
that are renamed in promoteInternals to avoid breaking inline
assembly references to them.
This relands commit
4474958d3a97dede2caa0920f7c4a4dc7aac57d3
with a fix to a use-of-uninitialized-value error that tripped
MemorySanitizer.
Link: https://github.com/ClangBuiltLinux/linux/issues/1354
Reviewed By: nickdesaulniers, pcc
Differential Revision: https://reviews.llvm.org/D104058
Zequan Wu [Tue, 15 Jun 2021 21:59:51 +0000 (14:59 -0700)]
[OpaquePtr] Mangle intrinsics with opaque pointers arguments
Mangling intrinsics with opaque pointer arguments using "op"+{address space}.
Differential Revision: https://reviews.llvm.org/D104272
Adrian Prantl [Wed, 23 Jun 2021 17:43:55 +0000 (10:43 -0700)]
clang-format llvm-dwarfdump.cpp
Adrian Prantl [Wed, 23 Jun 2021 17:43:38 +0000 (10:43 -0700)]
Improve error handling in llvm-dwarfdump.
Without this patch we're only showing a generic error message derived
from the error code to the end user.
rdar://
79378794
Differential Revision: https://reviews.llvm.org/D104483
Kuter Dinel [Sat, 19 Jun 2021 20:50:11 +0000 (23:50 +0300)]
[Attributor] Derive AAFunctionReachability attribute.
This attribute uses Attributor's internal 'optimistic' call graph
information to answer queries about function call reachability.
Functions can become reachable over time as new call edges are
discovered.
Reviewed By: jdoerfert
Differential Revision: https://reviews.llvm.org/D104599
William S. Moses [Wed, 23 Jun 2021 17:27:13 +0000 (13:27 -0400)]
Revert "[MLIR][LLVM] Expose type translator from LLVM to MLIR Type"
This reverts commit
5616a79398c7f10d92daf7d6387b195e95f2ac7e.
William S. Moses [Tue, 22 Jun 2021 17:57:04 +0000 (13:57 -0400)]
[MLIR][LLVM] Expose type translator from LLVM to MLIR Type
This commit moves the type translator from LLVM to MLIR to a public header for use by external projects or other code
Differential Revision: https://reviews.llvm.org/D104726
LLVM GN Syncbot [Wed, 23 Jun 2021 17:11:10 +0000 (17:11 +0000)]
[gn build] Port
560170fa2de5
zoecarver [Fri, 7 May 2021 00:39:53 +0000 (17:39 -0700)]
[libcxx][views] Add drop_view.
The first view in the libc++ ranges library 🚀
Differential Revision: https://reviews.llvm.org/D102037
Juneyoung Lee [Wed, 23 Jun 2021 17:03:07 +0000 (02:03 +0900)]
[ConstantFold] Allow propagation of poison for and/or i1
They were disallowed due to its bad interaction with select i1 -> and/or i1.
The transformation is now disabled by D101191, so let's revive this.
Nikita Popov [Wed, 23 Jun 2021 13:57:38 +0000 (15:57 +0200)]
[LAA] Make getPointersDiff() API compatible with opaque pointers
Make getPointersDiff() and sortPtrAccesses() compatible with opaque
pointers by explicitly passing in the element type instead of
determining it from the pointer element type.
The SLPVectorizer result is slightly non-optimal in that unnecessary
pointer bitcasts are added.
Differential Revision: https://reviews.llvm.org/D104784
Tomasz Miąsko [Wed, 23 Jun 2021 13:59:24 +0000 (15:59 +0200)]
[Demangle][Rust] Hide implementation details NFC
Move content of the "public" header into the implementation file.
This also renames two enumerations that were previously used through
`rust_demangle::` scope, to avoid breaking a build bot with older
version of GCC that rejects uses of enumerator through `E::A` if there
is a variable with the same name as enumeration `E` in the scope.
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D104362
Geoffrey Martin-Noble [Wed, 23 Jun 2021 16:25:36 +0000 (09:25 -0700)]
Update Bazel BUILD files up to
be9a87fe9b
Differential Revision: https://reviews.llvm.org/D104791
Vitali Lovich [Tue, 18 May 2021 20:57:07 +0000 (13:57 -0700)]
[clang-format] Add IfMacros option
https://bugs.llvm.org/show_bug.cgi?id=49354
Differential Revision: https://reviews.llvm.org/D102730
Sanjay Patel [Wed, 23 Jun 2021 15:31:22 +0000 (11:31 -0400)]
[ValueTracking] look through bitcast of vector in computeKnownBits
This borrows as much as possible from the SDAG version of the code
(originally added with D27129 and since updated with big endian support).
In IR, we can test more easily for correctness than we did in the
original patch. I'm using the simplest cases that I could find for
InstSimplify: we computeKnownBits on variable shift amounts to see if
they are zero or in range. So shuffle constant elements into a vector,
cast it, and shift it.
The motivating x86 example from https://llvm.org/PR50123 is also here.
We computeKnownBits in the caller code, but we only check if the shift
amount is in range. That could be enhanced to catch the 2nd x86 test -
if the shift amount is known too big, the result is 0.
Alive2 understands the datalayout and agrees that the tests here are
correct - example:
https://alive2.llvm.org/ce/z/KZJFMZ
Differential Revision: https://reviews.llvm.org/D104472
David Green [Wed, 23 Jun 2021 15:36:37 +0000 (16:36 +0100)]
[ARM] Limit v6m unrolling with multiple live outs
v6m cores only have a limited number of registers available. Unrolling
can mean we spend more on stack spills and reloads than we save from the
unrolling. This patch adds an extra heuristic to put a limit on the
unroll count for loops with multiple live out values, as measured from
the LCSSA phi nodes.
Differential Revision: https://reviews.llvm.org/D104659
Datta Nagraj [Wed, 23 Jun 2021 15:18:25 +0000 (11:18 -0400)]
[InstCombine] Eliminate casts to optimize ctlz operation
If a ctlz operation is performed on higher datatype and then
downcasted, then this can be optimized by doing a ctlz operation
on a lower datatype and adding the difference bitsize to the result
of ctlz to provide the same output:
https://alive2.llvm.org/ce/z/8uup9M
The original problem is shown in
https://llvm.org/PR50173
Differential Revision: https://reviews.llvm.org/D103788
Joel E. Denny [Wed, 23 Jun 2021 15:07:46 +0000 (11:07 -0400)]
[UpdateCCTestChecks][NFC] Permit other comments in common.py
Some parts of common.py already permit comment styles besides `;`.
Handle the remaining cases. Specifically, a future patch will extend
update_cc_test_checks.py to call add_global_checks.
Reviewed By: jdoerfert
Differential Revision: https://reviews.llvm.org/D104713
Craig Topper [Wed, 23 Jun 2021 15:04:42 +0000 (08:04 -0700)]
[RISCV] Add explicit copy to V0 in the masked vmsge(u).vx intrinsic handling.
This is consistent with our other masked vector instructions.
Previously we found cases where not doing this broke fast reg
alloc.
Sanjay Patel [Wed, 23 Jun 2021 14:11:13 +0000 (10:11 -0400)]
[InstCombine] convert FP min/max with negated op to fabs
This is part of improving floating-point patterns seen in:
https://llvm.org/PR39480
We don't require any FMF because the 2 potential corner cases
(-0.0 and NaN) are correctly handled without FMF:
1. -0.0 is treated as strictly less than +0.0 with
maximum/minimum, so fabs/fneg work as expected.
2. +/- 0.0 with maxnum/minnum is indeterminate, so
transforming to fabs/fneg is more defined.
3. The sign of a NaN may be altered by this transform,
but that is allowed in the default FP environment.
If there are FMF, they are propagated from the min/max call to
one or both new operands which seems to agree with Alive2:
https://alive2.llvm.org/ce/z/bem_xC
Ethan Stewart [Wed, 23 Jun 2021 14:25:00 +0000 (15:25 +0100)]
[OpenMP][AMDGCN] Apply fix for isnan, isinf and isfinite for amdgcn.
This fixes issues with various return types(bool/int) and was already
in place for nvptx headers, adjusted to work for amdgcn. This does
not affect hip as the change is guarded with OPENMP_AMDGCN.
Similar to D85879.
Reviewed By: jdoerfert, JonChesterfield, yaxunl
Differential Revision: https://reviews.llvm.org/D104677
Guillaume Chatelet [Wed, 23 Jun 2021 14:19:40 +0000 (14:19 +0000)]
[libc] add benchmarks for memcmp and bzero
Differential Revision: https://reviews.llvm.org/D104511
Jinsong Ji [Wed, 23 Jun 2021 13:38:38 +0000 (13:38 +0000)]
[DAGCombine] Check reassoc flags in aggressive fsub fusion
The is from discussion in https://reviews.llvm.org/D104247#inline-993387
The contract and reassoc flags shouldn't imply each other .
All the aggressive fsub fusion reassociate operations,
we should guard them with reassoc flag check.
Reviewed By: mcberg2017
Differential Revision: https://reviews.llvm.org/D104723
Joel E. Denny [Wed, 23 Jun 2021 13:39:04 +0000 (09:39 -0400)]
[OpenMP] Fix delete map type in ref count debug messages
For example, without this patch:
```
$ cat test.c
int main() {
int x;
#pragma omp target enter data map(alloc: x)
#pragma omp target enter data map(alloc: x)
#pragma omp target enter data map(alloc: x)
#pragma omp target exit data map(delete: x)
;
return 0;
}
$ clang -fopenmp -fopenmp-targets=nvptx64-nvidia-cuda test.c
$ LIBOMPTARGET_DEBUG=1 ./a.out |& grep 'Creating\|Mapping exists\|last'
Libomptarget --> Creating new map entry with HstPtrBegin=0x00007ffddf1eaea8, TgtPtrBegin=0x00000000013bb040, Size=4, RefCount=1, Name=unknown
Libomptarget --> Mapping exists with HstPtrBegin=0x00007ffddf1eaea8, TgtPtrBegin=0x00000000013bb040, Size=4, RefCount=2 (incremented), Name=unknown
Libomptarget --> Mapping exists with HstPtrBegin=0x00007ffddf1eaea8, TgtPtrBegin=0x00000000013bb040, Size=4, RefCount=3 (incremented), Name=unknown
Libomptarget --> Mapping exists with HstPtrBegin=0x00007ffddf1eaea8, TgtPtrBegin=0x00000000013bb040, Size=4, RefCount=2 (decremented)
Libomptarget --> There are 4 bytes allocated at target address 0x00000000013bb040 - is not last
```
`RefCount` is reported as decremented to 2, but it ought to be reset
because of the `delete` map type, and `is not last` is incorrect.
This patch migrates the reset of reference counts from
`DeviceTy::deallocTgtPtr` to `DeviceTy::getTgtPtrBegin`, which then
correctly reports the reset. Based on the `IsLast` result from
`DeviceTy::getTgtPtrBegin`, `targetDataEnd` then correctly reports `is
last` for any deletion. `DeviceTy::deallocTgtPtr` is responsible only
for the final reference count decrement and mapping removal.
An obscure side effect of this patch is that a `delete` map type when
the reference count is infinite yields `DelEntry=IsLast=false` in
`targetDataEnd` and so no longer results in a
`DeviceTy::deallocTgtPtr` call. Without this patch, that call is a
no-op anyway besides some unnecessary locking and mapping table
lookups.
Reviewed By: grokos
Differential Revision: https://reviews.llvm.org/D104560
Joel E. Denny [Wed, 23 Jun 2021 13:37:54 +0000 (09:37 -0400)]
[OpenMP] Improve ref count debug messages
For example, without this patch:
```
$ cat test.c
int main() {
int x;
#pragma omp target enter data map(alloc: x)
#pragma omp target exit data map(release: x)
;
return 0;
}
$ clang -fopenmp -fopenmp-targets=nvptx64-nvidia-cuda test.c
$ LIBOMPTARGET_DEBUG=1 ./a.out |& grep 'Creating\|Mapping exists'
Libomptarget --> Creating new map entry with HstPtrBegin=0x00007ffcace8e448, TgtPtrBegin=0x00007f12ef600000, Size=4, Name=unknown
Libomptarget --> Mapping exists with HstPtrBegin=0x00007ffcace8e448, TgtPtrBegin=0x00007f12ef600000, Size=4, updated RefCount=1
```
There are two problems in this example:
* `RefCount` is not reported when a mapping is created, but it might
be 1 or infinite. In this case, because it's created by `omp target
enter data`, it's 1. Seeing that would make later `RefCount`
messages easier to understand.
* `RefCount` is still 1 at the `omp target exit data`, but it's
reported as `updated`. The reason it's still 1 is that, upon
deletions, the reference count is generally not updated in
`DeviceTy::getTgtPtrBegin`, where the report is produced. Instead,
it's zeroed later in `DeviceTy::deallocTgtPtr`, where it's actually
removed from the mapping table.
This patch makes the following changes:
* Report the reference count when creating a mapping.
* Where an existing mapping is reported, always report a reference
count action:
* `update suppressed` when `UpdateRefCount=false`
* `incremented`
* `decremented`
* `deferred final decrement`, which replaces the misleading
`updated` in the above example
* Add comments to `DeviceTy::getTgtPtrBegin` to explain why it does
not zero the reference count. (Please advise if these comments miss
the point.)
* For unified shared memory, don't report confusing messages like
`RefCount=` or `RefCount= updated` given that reference counts are
irrelevant in this case. Instead, just report `for unified shared
memory`.
* Use `INFO` not `DP` consistently for `Mapping exists` messages.
* Fix device table dumps to print `INF` instead of `-1` for an
infinite reference count.
Reviewed By: jhuber6, grokos
Differential Revision: https://reviews.llvm.org/D104559
Louis Dionne [Tue, 22 Jun 2021 20:54:27 +0000 (16:54 -0400)]
[libc++] Remove ad-hoc modules tests that are now unnecessary
Since we now have modules-enabled CI, it is now redundant to have ad-hoc
tests that check arbitrary things about our modules support. Instead,
the whole test suite should pass with modules enabled, period.
This patch also removes the module cache path workaround: one would
expect that modules work properly without that workaround. If that
isn't the case and we do run into flaky test failures, we can re-enable
the workaround temporarily (but that would be very vexing and we should
fix Clang ASAP if that's the case).
Differential Revision: https://reviews.llvm.org/D104746
Roman Lebedev [Wed, 23 Jun 2021 13:41:16 +0000 (16:41 +0300)]
[NFC] Update arm_function_name.ll after
4de0c400317e5a92d57f2c76545061a9e7de22f8
serge-sans-paille [Tue, 15 Jun 2021 14:58:55 +0000 (16:58 +0200)]
Handle interactions between reserved identifier and user-defined suffixes
According to https://eel.is/c++draft/over.literal
> double operator""_Bq(long double); // OK: does not use the reserved identifier _Bq ([lex.name])
> double operator"" _Bq(long double); // ill-formed, no diagnostic required: uses the reserved identifier _Bq ([lex.name])
Obey that rule by keeping track of the operator literal name status wrt. leading whitespace.
Fix: https://bugs.llvm.org/show_bug.cgi?id=50644
Differential Revision: https://reviews.llvm.org/D104299
Jay Foad [Wed, 23 Jun 2021 13:37:20 +0000 (14:37 +0100)]
[AMDGPU] Remove unused multiclass MUBUF_Real_gfx10_with_name
Roman Lebedev [Wed, 23 Jun 2021 13:19:28 +0000 (16:19 +0300)]
[NFC][ARM] Fix update_llc_test_checks for thumbv7-apple-darwin, autogenerate thumb2-ifcvt1.ll
Roman Lebedev [Wed, 23 Jun 2021 13:09:38 +0000 (16:09 +0300)]
[NFC][AArch64] Autogenerate a few more tests
Roman Lebedev [Wed, 23 Jun 2021 12:34:29 +0000 (15:34 +0300)]
[NFC][ARM] Fix update_llc_test_checks for aarch64-apple-ios/thumbv7s-apple-darwin, autogenerate a few tests
Roman Lebedev [Wed, 23 Jun 2021 12:28:37 +0000 (15:28 +0300)]
[NFC][ARM] Fix update_llc_test_checks for thumbv7-apple-ios, autogenerate switch-minsize.ll
Roman Lebedev [Wed, 23 Jun 2021 12:22:02 +0000 (15:22 +0300)]
[NFC][ARM] Fix update_llc_test_checks for armv7-apple-ios, autogenerate ifcvt5.ll/ifcvt6.ll
Nikita Popov [Wed, 23 Jun 2021 13:26:54 +0000 (15:26 +0200)]
[ARMParallelDSP] Remove unnecessary wrapper function (NFC)
AreSequentialAccesses() forwards directly to isConsecutiveAccess()
and has an unnecessary template parameter to boot.
David Spickett [Wed, 23 Jun 2021 11:28:16 +0000 (11:28 +0000)]
[lldb] Remove asserts in CommandReturnObject SetError and AppendError
I added asserts to these in https://reviews.llvm.org/D104525.
They are available (directly or otherwise) via the API so we
should not assert.
Restore the previous behaviour. If the message
is empty, we return early before printing anything.
For SetError don't assert that the error is a failure.
The remaining assert is in AppendRawError which
is not part of the API.
Reviewed By: teemperor
Differential Revision: https://reviews.llvm.org/D104778
Raphael Isemann [Wed, 23 Jun 2021 13:06:12 +0000 (15:06 +0200)]
[lldb][NFC] Remove some redundant semicolons on HostInfoMacOSX
Rosie Sumpter [Tue, 22 Jun 2021 16:31:56 +0000 (17:31 +0100)]
[AArch64] Add CodeGen tests for vector reduction intrinsics. NFC
Tests are added for vector reduce OR, AND and XOR.
Differential Revision: https://reviews.llvm.org/D104771
owenca [Wed, 23 Jun 2021 09:40:29 +0000 (02:40 -0700)]
[clang-format] Fix a bug that indents else-comment-if incorrectly
PR50809
Differential Revision: https://reviews.llvm.org/D104774
Zarko Todorovski [Wed, 23 Jun 2021 11:14:24 +0000 (07:14 -0400)]
[AIX][PowerPC] Remove error when specifying mabi=vec-default on AIX
The default Altivec ABI was implemented but the clang error for specifying
its use still remains. Users could get around this but not specifying the
type of Altivec ABI but we need to remove the error.
Reviewed By: jsji
Differential Revision: https://reviews.llvm.org/D102094
Roman Lebedev [Wed, 23 Jun 2021 11:28:51 +0000 (14:28 +0300)]
[NFCI-ish][SimplifyCFGPass] Rework and generalize `ret` block tail-merging
This changes the approach taken to tail-merge the blocks
to always create a new block instead of trying to reuse some block,
and generalizes it to support dealing not with just the `ret` in the future.
This effectively lifts the CallBr restriction, although this isn't really intentional.
That is the only non-NFC change here, i'm not sure if it's reasonable/feasible to temporarily retain it.
Other restrictions of the transform remain.
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D104598
Hans Wennborg [Wed, 23 Jun 2021 08:35:55 +0000 (10:35 +0200)]
Add support for #pragma system_header with -fms-extensions
Clang already supports the pragma prefixed by "GCC" or "clang".
MSVC has more recently added support for the pragma, but without any prefix; see
https://devblogs.microsoft.com/cppblog/broken-warnings-theory/#external-headers
Differential revision: https://reviews.llvm.org/D104770
Juneyoung Lee [Mon, 21 Jun 2021 18:49:37 +0000 (03:49 +0900)]
[InstSimplify] Add more poison folding optimizations
This adds more poison folding optimizations to InstSimplify.
Since all binary operators propagate poison, these are fine.
Also, the precondition of `select cond, undef, x` -> `x` is relaxed to allow the case when `x` is undef.
Reviewed By: nikic
Differential Revision: https://reviews.llvm.org/D104661
David Spickett [Tue, 22 Jun 2021 16:12:56 +0000 (16:12 +0000)]
[lldb] Remove CommandReturnObject's SetError(StringRef)
Replacing existing uses with AppendError.
SetError is also part of the SBI API. This remains
but instead of calling the underlying SetError it
will call AppendError.
Reviewed By: teemperor
Differential Revision: https://reviews.llvm.org/D104768
Joe Ellis [Fri, 18 Jun 2021 14:53:53 +0000 (14:53 +0000)]
[Verifier] Fail on overrunning and invalid indices for {insert,extract} vector intrinsics
With regards to overrunning, the langref (llvm/docs/LangRef.rst)
specifies:
(llvm.experimental.vector.insert)
Elements ``idx`` through (``idx`` + num_elements(``subvec``) - 1)
must be valid ``vec`` indices. If this condition cannot be determined
statically but is false at runtime, then the result vector is
undefined.
(llvm.experimental.vector.extract)
Elements ``idx`` through (``idx`` + num_elements(result_type) - 1)
must be valid vector indices. If this condition cannot be determined
statically but is false at runtime, then the result vector is
undefined.
For the non-mixed cases (e.g. inserting/extracting a scalable into/from
another scalable, or inserting/extracting a fixed into/from another
fixed), it is possible to statically check whether or not the above
conditions are met. This was previously missing from the verifier, and
if the conditions were found to be false, the result of the
insertion/extraction would be replaced with an undef.
With regards to invalid indices, the langref (llvm/docs/LangRef.rst)
specifies:
(llvm.experimental.vector.insert)
``idx`` represents the starting element number at which ``subvec``
will be inserted. ``idx`` must be a constant multiple of
``subvec``'s known minimum vector length.
(llvm.experimental.vector.extract)
The ``idx`` specifies the starting element number within ``vec``
from which a subvector is extracted. ``idx`` must be a constant
multiple of the known-minimum vector length of the result type.
Similarly, these conditions were not previously enforced in the
verifier. In some circumstances, invalid indices were permitted
silently, and in other circumstances, an undef was spawned where a
verifier error would have been preferred.
This commit adds verifier checks to enforce the constraints above.
Differential Revision: https://reviews.llvm.org/D104468
Nikita Popov [Wed, 23 Jun 2021 10:21:12 +0000 (12:21 +0200)]
[TTI] Make assertion compatible with opaque pointers
Dropping the TODO here because it applies to all uses of this method.
Nikita Popov [Tue, 22 Jun 2021 21:34:38 +0000 (23:34 +0200)]
[LLParser] Remove special handling for call address space
Spin-off from D104740: I don't think this special handling is needed
anymore. Calls in textual IR are annotated with addrspace(N) (which
defaults to the program address space from data layout) and specifies
the expected pointer address space of the callee. There is no need
to special-case the program address space on top of that, as it
already is the default expected address space, and we shouldn't
allow use of the program address space if the call was explicitly
annotated with some other address space.
The IsCall parameter is retained because it will be used again soon.
Differential Revision: https://reviews.llvm.org/D104752
Nicolas Vasilache [Wed, 23 Jun 2021 09:03:08 +0000 (09:03 +0000)]
[mlir][LLVMIR] Fold ExtractValueOp coming from InsertValueOp
Differential Revision: https://reviews.llvm.org/D104769
Jay Foad [Fri, 4 Jun 2021 09:15:38 +0000 (10:15 +0100)]
[AMDGPU] Stop using LegacyLegalizerInfo. NFCI.
Differential Revision: https://reviews.llvm.org/D103684
Jay Foad [Fri, 11 Jun 2021 15:36:30 +0000 (16:36 +0100)]
[IR] Simplify createReplacementInstr
NFCI, although the test change shows that ConstantExpr::getAsInstruction
is better than the old implementation of createReplacementInstr because
it propagates things like the sdiv "exact" flag.
Differential Revision: https://reviews.llvm.org/D104124
Tobias Gysi [Wed, 23 Jun 2021 09:06:04 +0000 (09:06 +0000)]
[mlir][linalg] Change the FillOp library call signature.
Adapt the FillOp library call signature to the updated operand order introduced in https://reviews.llvm.org/D10412. The patch reverts the special treatment of FillOp in LinalgToStandard.
Differential Revision: https://reviews.llvm.org/D104360
Florian Hahn [Wed, 23 Jun 2021 09:29:58 +0000 (10:29 +0100)]
[llvm] Update tests that got missed in
adee485adf84ae8a.
Florian Hahn [Wed, 23 Jun 2021 08:42:45 +0000 (09:42 +0100)]
[SCEV] Support signed predicates in applyLoopGuards.
This adds handling for signed predicates, similar to how unsigned
predicates are already handled.
Reviewed By: nikic
Differential Revision: https://reviews.llvm.org/D104732
Florian Hahn [Tue, 22 Jun 2021 19:29:04 +0000 (20:29 +0100)]
[SCEV] Add tests with single-cond range check generated by InstComb.
Jay Foad [Tue, 22 Jun 2021 12:20:18 +0000 (13:20 +0100)]
[AMDGPU] Simplify collectReachableCallees. NFCI.
Don't use SCC iterators when we're only interested in reachability.
Use df_begin/df_end inline to find reachable nodes.
Differential Revision: https://reviews.llvm.org/D104704
Tobias Gysi [Wed, 23 Jun 2021 07:51:53 +0000 (07:51 +0000)]
[mlir][linalg] Adapt the FillOp builder signature.
Change the build operand order from output, value to value, output. The patch makes the argument order consistent with the pretty printed order updated by https://reviews.llvm.org/D104356.
Differential Revision: https://reviews.llvm.org/D104359
Stanislav Mekhanoshin [Tue, 15 Jun 2021 00:01:54 +0000 (17:01 -0700)]
[AMDGPU] Propagate LDS align into to instructions
Differential Revision: https://reviews.llvm.org/D104316
Martin Storsjö [Fri, 18 Jun 2021 12:20:13 +0000 (15:20 +0300)]
[LLD] [MinGW] Silence the printouts in one test. NFC.
This particular linker invocation is only run to check that we accept
options, but we don't inspect the generated command line. As all other
commands in the file have their output piped to FileCheck, the lit test
doesn't print any other output; therefore silence this one for consistency
as well.
Fangrui Song [Wed, 23 Jun 2021 07:31:52 +0000 (00:31 -0700)]
[llvm-objcopy][MachO] Fix namespace style issues
Martin Storsjö [Fri, 18 Jun 2021 11:33:28 +0000 (14:33 +0300)]
[LLD] [MinGW] Print the lld-link command to stderr
This is consistent with how clang prints its internal commands with
-### and -v.
When linking with -verbose, we get log messages from the actual
linking written to stderr. By printing the command to the same stream,
we make sure they appear in a sensible chronological order.
Differential Revision: https://reviews.llvm.org/D104527
Tobias Gysi [Wed, 23 Jun 2021 06:28:58 +0000 (06:28 +0000)]
[mlir][linalg] Change the pretty printed FillOp operand order.
The patch changes the pretty printed FillOp operand order from output, value to value, output. The change is a follow up to https://reviews.llvm.org/D104121 that passes the fill value using a scalar input instead of the former capture semantics.
Differential Revision: https://reviews.llvm.org/D104356
Vinayaka Bandishti [Wed, 23 Jun 2021 06:55:09 +0000 (12:25 +0530)]
[MLIR] Generalize detecting mods during slice computing
During slice computation of affine loop fusion, detect one id as the mod
of another id w.r.t a constant in a more generic way. Restrictions on
co-efficients of the ids is removed. Also, information from the
previously calculated ids is used for simplification of affine
expressions, e.g.,
If `id1` = `id2`,
`id_n - divisor * id_q - id_r + id1 - id2 = 0`, is simplified to:
`id_n - divisor * id_q - id_r = 0`.
If `c` is a non-zero integer,
`c*id_n - c*divisor * id_q - c*id_r = 0`, is simplified to:
`id_n - divisor * id_q - id_r = 0`.
Reviewed By: bondhugula, ayzhuang
Differential Revision: https://reviews.llvm.org/D104614
Vinayaka Bandishti [Wed, 23 Jun 2021 06:53:14 +0000 (12:23 +0530)]
[NFC][PDL] Fix documentation typo, redundant test
Correct a documentation typo, and delete a duplicate test in
`pdl-to-pdl-interp-rewriter.mlir`.
Reviewed By: pr4tgpt, bondhugula, rriddle
Differential Revision: https://reviews.llvm.org/D104688
Martin Storsjö [Wed, 23 Jun 2021 06:54:16 +0000 (09:54 +0300)]
Revert "[AArch64LoadStoreOptimizer] Recommit: Generate more STPs by renaming registers earlier"
This reverts commit
ea011ec5ed53599305de62ca5fcfd31f4b3448c3.
This still causes some miscompiles, I'll follow up in the phabricator
review with a sample of that issue (which is part of the sample of
the previous issue).
Igor Kudrin [Wed, 23 Jun 2021 06:26:56 +0000 (13:26 +0700)]
[TableGen] Fix printing second PC-relative operand
If an instruction has several operands and a PC-relative one is not the
first of them, the generator may produce the code that does not pass the
'Address' parameter to the printout method. For example, for an Arm
instruction 'LE LR, $imm', it reuses the same code as for other
instructions where the second operand is not PC-relative:
void ARMInstPrinter::printInstruction(...) {
...
case 11:
// BF16VDOTI_VDOTD, BF16VDOTI_VDOTQ, BF16VDOTS_VDOTD, ...
printOperand(MI, 1, STI, O);
O << ", ";
printOperand(MI, 2, STI, O);
break;
...
The patch fixes that by considering 'PCRel' when comparing
'AsmWriterOperand' values.
Differential Revision: https://reviews.llvm.org/D104698
Min-Yih Hsu [Wed, 23 Jun 2021 05:58:15 +0000 (22:58 -0700)]
[M68k] Fix incorrect #include-ed file in M68kSubtarget
In https://reviews.llvm.org/rG2193347e72fa , a cpp file is accidentally
included instead of its header file counterpart. This patch fixes this
error.
Jim Lin [Wed, 23 Jun 2021 05:26:56 +0000 (13:26 +0800)]
[M68k] Add testcases for shift and rotate instructions
Add codegen testcases for lsl, lsr, asr, rol and ror instructions.
Reviewed By: myhsu
Differential Revision: https://reviews.llvm.org/D104685
Jim Lin [Wed, 23 Jun 2021 05:25:23 +0000 (13:25 +0800)]
[M68k] Refactor codegen patterns for logic operations and add tests for it
Refactor pat for and, or and xor operation and add missing tests for it
Reviewed By: myhsu
Differential Revision: https://reviews.llvm.org/D104626
Max Kazantsev [Wed, 23 Jun 2021 04:51:36 +0000 (11:51 +0700)]
[LoopDeletion] Exploit undef Phi inputs when symbolically executing 1st iteration
Follow-up on Roman's idea expressed in D103959.
- If a Phi has undefined inputs from live blocks:
- and no other inputs, assume it is undef itself;
- and exactly one non-undef input, we can assume that all undefs are equal to this input.
Differential Revision: https://reviews.llvm.org/D104618
Reviewed By: lebedev.ri, nikic
Zequan Wu [Wed, 23 Jun 2021 04:46:21 +0000 (21:46 -0700)]
Revert "[CodeGen] Don't create fake FunctionDecls when generating block/byref"
That commit causes crash with error "!dbg attachment points at wrong subprogram for function" on iOS platforms.
This reverts commit
f4c06bcb67a1eba13a7f164961586dddaf8ebd5f.
Max Kazantsev [Wed, 23 Jun 2021 04:33:03 +0000 (11:33 +0700)]
[Test] Clear out br i1 undef from tests to avoid UB
We don't want to test possible unexpected impact of such
branches. Replacing them with regular conditions. Idea by
Nikita Popov.
Max Kazantsev [Wed, 23 Jun 2021 03:43:06 +0000 (10:43 +0700)]
[LSR] Filter out zero factors. PR50765
Zero factor leads to division by zero and failure of corresponding
assert as shown in PR50765. We should filter out such factors.
Differential Revision: https://reviews.llvm.org/D104702
Reviewed By: huihuiz, reames
Jack Xia [Wed, 23 Jun 2021 03:17:00 +0000 (11:17 +0800)]
Fix typo in Toy Tutorial Ch-4
multiple_transpose -> multiply_transpose
River Riddle [Wed, 23 Jun 2021 03:16:10 +0000 (03:16 +0000)]
[mlir] Fix GCC5 build after D104516
GCC5 isn't able to implicitly capture `this` properly in an `auto` lambda.
River Riddle [Wed, 23 Jun 2021 03:03:27 +0000 (03:03 +0000)]
[mlir][OpDefGen] Don't emit attribute name getters when there are no attributes
This avoids generating otherwise unnecessary methods.
Joseph Huber [Tue, 22 Jun 2021 03:35:45 +0000 (23:35 -0400)]
[OpenMP] Introduce an CMake find module for OpenMP Target support
This introduces a CMake find module for detecting target offloading support in
a compiler. The goal is to make it easier to incorporate target offloading into
a cmake project.
Reviewed By: tianshilei1992
Differential Revision: https://reviews.llvm.org/D104710
River Riddle [Wed, 23 Jun 2021 02:52:05 +0000 (02:52 +0000)]
[mlir] Fix slicing-utils.mlir test after D104516
Remove the duplicate unnecessary CHECK labels at the bottom of the file.
Nico Weber [Wed, 23 Jun 2021 02:21:18 +0000 (22:21 -0400)]
[gn build] don't build ubsan_minimal on mac
It doesn't build there, see http://45.33.8.238/macm1/12180/step_4.txt
River Riddle [Wed, 23 Jun 2021 01:16:55 +0000 (01:16 +0000)]
[mlir] Add a ThreadPool to MLIRContext and refactor MLIR threading usage
This revision refactors the usage of multithreaded utilities in MLIR to use a common
thread pool within the MLIR context, in addition to a new utility that makes writing
multi-threaded code in MLIR less error prone. Using a unified thread pool brings about
several advantages:
* Better thread usage and more control
We currently use the static llvm threading utilities, which do not allow multiple
levels of asynchronous scheduling (even if there are open threads). This is due to
how the current TaskGroup structure works, which only allows one truly multithreaded
instance at a time. By having our own ThreadPool we gain more control and flexibility
over our job/thread scheduling, and in a followup can enable threading more parts of
the compiler.
* The static nature of TaskGroup causes issues in certain configurations
Due to the static nature of TaskGroup, there have been quite a few problems related to
destruction that have caused several downstream projects to disable threading. See
D104207 for discussion on some related fallout. By having a ThreadPool scoped to
the context, we don't have to worry about destruction and can ensure that any
additional MLIR thread usage ends when the context is destroyed.
Differential Revision: https://reviews.llvm.org/D104516
River Riddle [Wed, 23 Jun 2021 01:16:43 +0000 (01:16 +0000)]
[mlir][NFC] Cleanup the MLIRTestReducer pass
Christopher Di Bella [Tue, 22 Jun 2021 19:21:46 +0000 (19:21 +0000)]
[libcxx][NFC] prepares `<type_traits>` for moving out forward and swap
* `<type_traits>` depends on `std::forward`, so we replaced it with
`static_cast<T&&>`.
* `swap`'s return type is confusing, so it's been rearranged to improve
readabilitiy.
Jon Roelofs [Thu, 10 Jun 2021 23:48:45 +0000 (16:48 -0700)]
[Remarks] Make memsize remarks report as an analysis, not a missed opportunity.
Differential revision: https://reviews.llvm.org/D104078