Age | Commit message (Collapse) | Author | Files | Lines |
|
|
|
Several unit test folders were missing from the bazel build, including: Transforms, Conversion, Rewrite
|
|
|
|
Unit tests are not getting built as part of bazel runs.
Reviewed By: mehdi_amini, GMNGeoffrey
Differential Revision: https://reviews.llvm.org/D116046
|
|
This reverts 3816c53f040cc6aa06425978dd504b0bd5b7899c and removes follow-up
fixups.
The original intention was to show error earlier (posix_fallocate time) than
later for ld.lld but it appears to cause some problems which make it not free.
* FreeBSD ZFS: EINVAL, not too bad.
* FreeBSD UFS: according to khng "devastatingly slow on freebsd because UFS on freebsd does not have preallocation support like illumos. It zero-fills."
* NetBSD: maybe EOPNOTSUPP
* Linux tmpfs: unless tmpfs is set up to use huge pages (requires CONFIG_TRANSPARENT_HUGE_PAGECACHE=y), I can consistently demonstrate ~300ms delay for a 1.4GiB output.
* Linux ext4: I don't measure any benefit, either backed by a hard disk or by a file in tmpfs.
* The current code organization of `defined(HAVE_POSIX_FALLOCATE)` costs us a macro dispatch for AIX.
I think we should just remove it. I think if posix_fallocate ever finds demonstrable benefit,
it is likely Linux specific and will not need HAVE_POSIX_FALLOCATE, and possibly opt-in by some specific programs.
In a filesystem with CoW and compression, the ENOSPC benefit may be lost as well.
Reviewed By: khng300
Differential Revision: https://reviews.llvm.org/D115957
|
|
deciding the parallelization granularity.
Reviewed By: ezhulenev, mehdi_amini
Differential Revision: https://reviews.llvm.org/D115423
|
|
https://github.com/llvm/llvm-project/commit/65d7fd0239bf301c5dcaa26ed474200845966136
|
|
`EnumAttr` is a pure TableGen implementation of enum attributes using `AttrDef`. This is meant as a drop-in replacement for `StrEnumAttr`, which is soon to be deprecated. `StrEnumAttr` is often used over `IntEnumAttr` because its more readable in MLIR assembly formats. However, storing and manipulating strings is not efficient. Defining `StrEnumAttr` can also be awkward and relies on a lot of special logic in `EnumsGen`, and has some hidden sharp edges.
Also, `EnumAttr` stores the enum directly, removing the need to convert to/from integers when calling attribute getters on ops.
Reviewed By: mehdi_amini
Differential Revision: https://reviews.llvm.org/D115181
|
|
ec37e0bbafab75fa64f1ddb4cdeceb5400491ef8
|
|
Adding missing dependences.
|
|
This patch extends the GPU kernel outlining pass so that it can take in
an optional data layout specification that will be attached to the GPU
module operation generated. If the data layout specification is not provided
the default data layout is used instead.
Reviewed By: herhut, mehdi_amini
Differential Revision: https://reviews.llvm.org/D115722
|
|
This is a new pattern rewrite frontend designed from the ground
up to support MLIR constructs, and to target PDL. This frontend
language was proposed in https://llvm.discourse.group/t/rfc-pdll-a-new-declarative-rewrite-frontend-for-mlir/4798
This commit starts sketching out the base structure of the
frontend, and is intended to be a minimal starting point for
building up the language. It essentially contains support for
defining a pattern, variables, and erasing an operation. The
features mentioned in the proposal RFC (including IDE support)
will be added incrementally in followup commits.
I intend to upstream the documentation for the language in a
followup when a bit more of the pieces have been landed.
Differential Revision: https://reviews.llvm.org/D115093
|
|
|
|
|
|
|
|
After removing the range type, Linalg does not define any type. The revision thus consolidates the LinalgOps.h and LinalgTypes.h into a single Linalg.h header. Additionally, LinalgTypes.cpp is renamed to LinalgDialect.cpp to follow the convention adopted by other dialects such as the tensor dialect.
Depends On D115727
Reviewed By: nicolasvasilache
Differential Revision: https://reviews.llvm.org/D115728
|
|
|
|
|
|
Instead of modifying the existing linalg.tiled_loop op, create a new op with memref input/outputs and delete the old op.
Differential Revision: https://reviews.llvm.org/D115493
|
|
Instead of modifying the existing scf.for op, create a new op with memref OpOperands/OpResults and delete the old op.
New allocations / other memrefs can now be yielded from the loop. This functionality is deactivated by default and guarded against by AssertDestinationPassingStyle.
This change also introduces `replaceOp`, which will be utilized by all other `bufferize` implementations in future commits. Bufferization will then no longer rely on old (pre-bufferize) ops to DCE away. Instead old ops are deleted on the spot. This improves debuggability because there won't be any duplicate ops anymore (bufferized + not-yet-bufferized) when dumping IR during bufferization. It is also less fragile because unbufferized IR can no longer silently "hang around" due to an implementation bug.
Differential Revision: https://reviews.llvm.org/D114926
|
|
In 2015-05, GCC added the configure option `--enable-default-pie`. When enabled,
* in the absence of -fno-pic/-fpie/-fpic (and their upper-case variants), -fPIE is the default.
* in the absence of -no-pie/-pie/-shared/-static/-static-pie, -pie is the default.
This has been adopted by all(?) major distros.
I think default PIE is the majority in the Linux world, but
--disable-default-pie users is not that uncommon because GCC upstream hasn't
switched the default yet (https://gcc.gnu.org/PR103398).
This patch add CLANG_DEFAULT_PIE_ON_LINUX which allows distros to use default PIE.
The option is justified as its adoption can be very high among Linux distros
to make Clang default match GCC, and is likely a future-new-default, at which
point we will remove CLANG_DEFAULT_PIE_ON_LINUX.
The lit feature `default-pie-on-linux` can be handy to exclude default PIE sensitive tests.
Reviewed By: foutrelis, sylvestre.ledru, thesamesam
Differential Revision: https://reviews.llvm.org/D113372
|
|
Needed after 34491ca7291c
|
|
This patch provides a draft overlay to support compilation of llvm libc with Bazel.
Tested on linux x86-64 with
```
cd git/llvm-project/utils/bazel
bazelisk-linux-amd64 build --sandbox_base=/dev/shm --config=generic_clang @llvm-project//libc:all
```
Differential Revision: https://reviews.llvm.org/D114712
|
|
bc657b2eef82f604e5bfb8da421cbdfc80156739 adds the dependency to
MemRefDialect.
Reviewed By: GMNGeoffrey, mehdi_amini
Differential Revision: https://reviews.llvm.org/D115558
|
|
RFC: https://llvm.discourse.group/t/rfc-reshape-ops-restructuring/3310
linalg.fill gets a canonicalizer, because `FoldFillWithTensorReshape` cannot be moved to tensorops (it uses linalg::FillOp inside). Before it was listed as a canonicalization pattern for the reshape operations, now it became a canonicalization for FillOp.
Differential Revision: https://reviews.llvm.org/D115502
|
|
Reviewed By: mehdi_amini
Differential Revision: https://reviews.llvm.org/D115487
|
|
Until we figure MLGO + bazel, exclude this unittest (same as
TFUtilsTest.cpp)
Differential Revision: https://reviews.llvm.org/D115472
|
|
This passes bufferizes FuncOp bodies, but not FuncOp boundaries.
Differential Revision: https://reviews.llvm.org/D114671
|
|
|
|
dialect ops
This change provides `BufferizableOpInterface` implementations for ops from the Bufferization dialects. These ops are needed at the bufferization boundaries for partial bufferization.
Differential Revision: https://reviews.llvm.org/D114618
|
|
This cmake configure option was added in
df0ba47c36f6bd0865e3286853b76d37e037c2d7, and was ported to
Bazel in 7d323dc7738e3152c4bd54a23ac27554bfbbf583.
However, the setting chosen in Bazel seems accidental, not necessarily
intentional.
LLVM_WINDOWS_PREFER_FORWARD_SLASH has no effect on Unix, and on
Windows, setting it to 0 is the default, which gets the same behaviour
as before. Setting it to 1 enables new experimental behaviours
(which is enabled by default on MinGW targets only).
As I don't see any explicit intent to opt in to the new experimental
behaviour, I believe the current configuration in bazel was a
mistake.
Differential Revision: https://reviews.llvm.org/D114065
|
|
|
|
|
|
This code and cmake was removed in https://reviews.llvm.org/D114842
Differential Revision: https://reviews.llvm.org/D114976
|
|
Updates Bazel files for 9e3552523ebd3385487e01e3e7af37b8c0efaf57
|
|
They aren't needed anymore, we handle conditional compilation in those
files.
Reviewed By: GMNGeoffrey
Differential Revision: https://reviews.llvm.org/D114970
|
|
|
|
|
|
[RFC](https://llvm.discourse.group/t/rfc-dialect-for-bufferization-related-ops/4712)
Differential Revision: https://reviews.llvm.org/D114698
|
|
Bufferization of function boundaries is extracted from ComprehensiveBufferize into a separate file. This will become its own build target in the future.
Differential Revision: https://reviews.llvm.org/D114226
|
|
This makes ComprehensiveBufferize entirely independent of the Affine dialect.
Differential Revision: https://reviews.llvm.org/D114222
|
|
https://llvm.discourse.group/t/rfc-dialect-for-bufferization-related-ops/4712
Differential Revision: https://reviews.llvm.org/D114552
|
|
This makes ComprehensiveBufferize entirely independent of the SCF dialect.
Differential Revision: https://reviews.llvm.org/D114221
|
|
This makes ComprehensiveBufferize entirely independent of the arith dialect.
Differential Revision: https://reviews.llvm.org/D114219
|
|
This makes ComprehensiveBufferize entirely independent of the vector dialect.
Differential Revision: https://reviews.llvm.org/D114218
|
|
This makes ComprehensiveBufferize entirely independent of the tensor dialect.
Differential Revision: https://reviews.llvm.org/D114217
|
|
- Fixes a minor issue in https://reviews.llvm.org/D114338, which seems incorrectly
added the llvm:AllTargetsAsmParsers dependency to Translation in bazel build files.
Differential Revision: https://reviews.llvm.org/D114471
|
|
Bufferize/IR/AllocationOpInterface.td.""
This reverts and fixes commit de18b7dee6a81e5e790c8e8060065b1ef72d13ed.
|
|
inline_asm)
This revision follows up on the conversation titled:
```[llvm-dev] Understanding and controlling some of the AVX shuffle emission paths```
The revision adds a vblendps-based implementation for transpose8x8 and further distinguishes between and intrinsics and an inline_asm implementation.
This results in roughly 20% fewer cycles as reported by llvm-mca:
After this revision (intrinsic version, resolves to virtually identical assembly as per the llvm-dev discussion, no vblendps instruction is emitted):
```
Iterations: 100
Instructions: 5900
Total Cycles: 2415
Total uOps: 7300
Dispatch Width: 6
uOps Per Cycle: 3.02
IPC: 2.44
Block RThroughput: 24.0
Cycles with backend pressure increase [ 89.90% ]
Throughput Bottlenecks:
Resource Pressure [ 89.65% ]
- SKXPort1 [ 0.04% ]
- SKXPort2 [ 12.42% ]
- SKXPort3 [ 12.42% ]
- SKXPort5 [ 89.52% ]
Data Dependencies: [ 37.06% ]
- Register Dependencies [ 37.06% ]
- Memory Dependencies [ 0.00% ]
```
After this revision (inline_asm version, vblendps instructions are indeed emitted):
```
Iterations: 100
Instructions: 6300
Total Cycles: 2015
Total uOps: 7700
Dispatch Width: 6
uOps Per Cycle: 3.82
IPC: 3.13
Block RThroughput: 20.0
Cycles with backend pressure increase [ 83.47% ]
Throughput Bottlenecks:
Resource Pressure [ 83.18% ]
- SKXPort0 [ 14.49% ]
- SKXPort1 [ 14.54% ]
- SKXPort2 [ 19.70% ]
- SKXPort3 [ 19.70% ]
- SKXPort5 [ 83.03% ]
- SKXPort6 [ 14.49% ]
Data Dependencies: [ 39.75% ]
- Register Dependencies [ 39.75% ]
- Memory Dependencies [ 0.00% ]
```
An accessible copy of the conversation is available [here](https://gist.github.com/nicolasvasilache/68c7f34012584b0e00f335bcb374ede0).
Differential Revision: https://reviews.llvm.org/D114393
|
|
This is in preparation of changing the op traversal during bufferization.
Differential Revision: https://reviews.llvm.org/D114040
|