This reduces the maintenance burden by using globs, which is the
tradeoff we make in the other LLVM Bazel build files as well.
Reviewed By: mehdi_amini
Differential Revision: https://reviews.llvm.org/D109720
Conversion to the LLVM dialect is being refactored to be more progressive and
is now performed as a series of independent passes converting different
dialects. These passes may produce `unrealized_conversion_cast` operations that
represent pending conversions between built-in and LLVM dialect types.
Historically, a more monolithic Standard-to-LLVM conversion pass did not need
these casts as all operations were converted in one shot. Previous refactorings
have led to the requirement of running the Standard-to-LLVM conversion pass to
clean up `unrealized_conversion_cast`s even though the IR had no standard
operations in it. The pass must have been also run the last among all to-LLVM
passes, in contradiction with the partial conversion logic. Additionally, the
way it was set up could produce invalid operations by removing casts between
LLVM and built-in types even when the consumer did not accept the uncasted
type, or could lead to cryptic conversion errors (recursive application of the
rewrite pattern on `unrealized_conversion_cast` as a means to indicate failure
to eliminate casts).
In fact, the need to eliminate A->B->A `unrealized_conversion_cast`s is not
specific to to-LLVM conversions and can be factored out into a separate type
reconciliation pass, which is achieved in this commit. While the cast operation
itself has a folder pattern, it is insufficient in most conversion passes as
the folder only applies to the second cast. Without complex legality setup in
the conversion target, the conversion infra will either consider the cast
operations valid and not fold them (a separate canonicalization would be
necessary to trigger the folding), or consider the first cast invalid upon
generation and stop with error. The pattern provided by the reconciliation pass
applies to the first cast operation instead. Furthermore, having a separate
pass makes it clear when `unrealized_conversion_cast`s could not have been
eliminated since it is the only reason why this pass can fail.
Reviewed By: nicolasvasilache
Differential Revision: https://reviews.llvm.org/D109507
OpenMP reductions need a neutral element, so we match some known reduction
kinds (integer add/mul/or/and/xor, float add/mul, integer and float min/max) to
define the neutral element and the atomic version when possible to express
using atomicrmw (everything except float mul). The SCF-to-OpenMP pass becomes a
module pass because it now needs to introduce new symbols for reduction
declarations in the module.
Reviewed By: chelini
Differential Revision: https://reviews.llvm.org/D107549
An interface to allow for tiling of operations is introduced. The
tiling of the linalg.pad_tensor operation is modified to use this
interface.
Differential Revision: https://reviews.llvm.org/D108611
* Add `DimOfIterArgFolder`.
* Move existing cross-dialect canonicalization patterns to `LoopCanonicalization.cpp`.
* Rename `SCFAffineOpCanonicalization` pass to `SCFForLoopCanonicalization`.
* Expand documentaton of scf.for: The type of loop-carried variables may not change with iterations. (Not even the dynamic type.)
Differential Revision: https://reviews.llvm.org/D108806
This canonicalization simplifies affine.min operations inside "for loop"-like operations (e.g., scf.for and scf.parallel) based on two invariants:
* iv >= lb
* iv < lb + step * ((ub - lb - 1) floorDiv step) + 1
This commit adds a new pass `canonicalize-scf-affine-min` (instead of being a canonicalization pattern) to avoid dependencies between the Affine dialect and the SCF dialect.
Differential Revision: https://reviews.llvm.org/D107731
There's a lot of unnecessary backslashes here that we can avoid to
reduce confusion.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D108495
Apply the "for loop peeling" pattern from SCF dialect transforms. This pattern splits scf.for loops into full and partial iterations. In the full iteration, all masked loads/stores are canonicalized to unmasked loads/stores.
Differential Revision: https://reviews.llvm.org/D107733
Simplify affine.min ops, enabling various other canonicalizations inside the peeled loop body.
affine.min ops such as:
```
map = affine_map<(d0)[s0, s1] -> (s0, -d0 + s1)>
%r = affine.min #affine.min #map(%iv)[%step, %ub]
```
are rewritten them into (in the case the peeled loop):
```
%r = %step
```
To determine how an affine.min op should be rewritten and to prove its correctness, FlatAffineConstraints is utilized.
Differential Revision: https://reviews.llvm.org/D107222
Only require one intermediate repository instead of two.
Fewer parameters in llvm_config.
Second attempt of https://reviews.llvm.org/D107714, this time also updating `third_party_build` and `deps_impl` paths.
Reviewed By: GMNGeoffrey
Differential Revision: https://reviews.llvm.org/D108274
c1ebefdf77 "[mlir] Make polynomial approximation emit
std instead of LLVM ops" removed the dependence on LLVMDialect.
Remove the dependence also from BUILD.bazel.
Reviewed By: bkramer
Differential Revision: https://reviews.llvm.org/D107908
The `llvm-stress` binary is currently missing from the Bazel `BUILD` file for llvm. This patch adds it.
Reviewed By: GMNGeoffrey
Differential Revision: https://reviews.llvm.org/D107571
This patch adds a Bazel configuration to build lld. That includes a
BUILD.bazel file to export the libunwind headers for use by lld. Since
the lld target itself requires libxml2 (through WindowsManifest) it's
currently disabled on Buildkite and marked manual, but all the libraries
build.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D107414
Includes can now be fully managed via td_library and specified locally
to the tablegen files that require them. This has been deprecated for a
while and is not used upstream. I'm not aware of any downstream users
either.
Reviewed By: jpienaar
Differential Revision: https://reviews.llvm.org/D107389
Updates the Bazel configuration for
https://github.com/llvm/llvm-project/commit/ee7d20e84675. We need to
drop the dependency from llvm-tblgen to avoid a dependency cycle:
```
.-> @llvm-project//llvm:llvm-tblgen
| @llvm-project//llvm:tblgen
| @llvm-project//llvm:MC
| @llvm-project//llvm:ProfileData
| @llvm-project//llvm:Core
| @llvm-project//llvm:attributes_gen
| @llvm-project//llvm:include/llvm/IR/Attributes.inc
| @llvm-project//llvm:attributes_gen__gen_attrs_genrule
`-- @llvm-project//llvm:llvm-tblgen
```
It appears this dep was not strictly necessary though. TableGen uses MC
headers but it can get those through Support, which also exports MC
headers due to layering issues.
Differential Revision: https://reviews.llvm.org/D107480
Add ForLoopBoundSpecialization pass, which specializes scf.for loops into a "main loop" where `step` divides the iteration space evenly and into an scf.if that handles the last iteration.
This transformation is useful for vectorization and loop tiling. E.g., when vectorizing loads/stores, programs will spend most of their time in the main loop, in which only unmasked loads/stores are used. Only the in the last iteration (scf.if), slower masked loads/stores are used.
Subsequent commits will apply this transformation in the SparseDialect and in Linalg's loop tiling.
Differential Revision: https://reviews.llvm.org/D105804
This patch makes it possible to list a td_library as a rule's data
attribute and get its source files and all its transitive dependencies
at runtime. This is useful for, e.g. shell tests running tblgen.
Note that this is a bit different from how a "normal" (e.g. C++) library
rule would work because those have actual library outputs and the
td_library rule just bundles some source files and includes. If someone
wanted to make use of the includes, they would have to access the TdInfo
provider, but this keeps simple things simple.
Reviewed By: jpienaar
Differential Revision: https://reviews.llvm.org/D106922
These are unconditionally included in the CMake build as well and
necessary for some odd platforms (even though the C++11 standard says
they shouldn't be).
Reviewed By: chandlerc
Differential Revision: https://reviews.llvm.org/D107123
This makes the logic used to determine if targets have the given
features the same as is used in CMake. Incidentally, it enables these
features for the targets added in https://reviews.llvm.org/D106921
which were missing because this was previously a hardcoded list.
Reviewed By: chandlerc
Differential Revision: https://reviews.llvm.org/D107019
I apparently left in the old digest when updating the version, so for my
local build Bazel just happily used the cached version, but anyone
attempting a fresth build would get a mismatch.
Differential Revision: https://reviews.llvm.org/D107010
Added the following targets to the LLVM Bazel overlay:
AVR
Mips
MPS430
SystemZ
XCore
Reviewed By: GMNGeoffrey
Differential Revision: https://reviews.llvm.org/D106921
This adds Bazel configuration for the TargetMCA targets, which currently
only includes AMDGPU.
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D106996
This is the last instance of td_srcs in MLIR core build files. `deps` is
generally preferred. There are still some cases where `td_srcs` is
useful where creating a td_library would just be another layer of
indirection, so not (yet) dropping it entirely.
Differential Revision: https://reviews.llvm.org/D106716
When using `llvm_zlib_external` rule with `external_zlib` attribute set to a
label referring to the main repository, like `@//third_party/zlib`, it will be
replaced with `//third_party/zlib` after template substitution. This will then
attempt to find `//third_party/zlib` within the local repository
`@llvm_zlib//third_party/zlib`, which does not exist, rather than the intended
reference back to the main repository. The issue appears to be that the
conversion of `Label` type to string with
`str(repository_ctx.attr.external_zlib)`, which is causing the main repository
qualifier to be lost.
This diff fixes the issue by changing the `external_zlib` attribute to
`attr.string` type rather than `attr.label`.
In future a more elegant solution may be possible that preserves use of the
`Label` type, depending on resolution of the issue
https://github.com/bazelbuild/bazel/issues/13731.
Ported from Github PR https://github.com/google/llvm-bazel/pull/236.
Reviewed By: GMNGeoffrey
Differential Revision: https://reviews.llvm.org/D106606
The `reifyReturnTypeShapesPerResultDim` method supports shape
inference for rsults that are ranked types. These are used lower in
the codegeneration stack than its counter part `reifyReturnTypeShapes`
which also supports unranked types, and is more suited for use higher
up the compilation stack. To have separation of concerns, this method
is split into its own interface.
See discussion : https://llvm.discourse.group/t/better-layering-for-infershapedtypeopinterface/3823
Differential Revision: https://reviews.llvm.org/D106133
This avoids Bazel recursing into these directories when overlayed, which
will break if someone has run Bazel in these dirs (which would only be
successful with the http_archive example) because of the Bazel directory
symlinks (already gitignored).
Reviewed By: jpienaar
Differential Revision: https://reviews.llvm.org/D105357
Add explicit coverage provider. Also remove output_to_genfiles which
isn't necessary for this test (it's just copy-pasta from gentbl_rule,
which needs it for output C++ header files).
Reviewed By: jpienaar
Differential Revision: https://reviews.llvm.org/D106115
This has been deprecated for a while. There are no users in tree and I'm
not aware of any out of tree users either.
Reviewed By: ftynse
Differential Revision: https://reviews.llvm.org/D106114
This may be necessary in partial multi-stage conversion when a container type
from dialect A containing types from dialect B goes through the conversion
where only dialect A is converted to the LLVM dialect. We will need to keep a
pointer-to-non-LLVM type in the IR until a further conversion can convert
dialect B types to LLVM types.
Reviewed By: wsmoses
Differential Revision: https://reviews.llvm.org/D106076
CMake would have no restrictions on this and the custom list is a pain
to maintain.
Reviewed By: jpienaar
Differential Revision: https://reviews.llvm.org/D106003
Users should generally observe no difference as long as they don't use
unintended option forms. Behavior changes:
* `-t=d` is removed. Use `-t d` instead.
* `--demangle=false` and `--demangle=0` cannot be used. Omit the option or use `--no-demangle`. Other flag-style options don't have `--no-` forms.
* `--help-list` is removed. This is a `cl::` specific option.
* llvm-readobj now supports grouped short options as well.
* `--color` is removed. This is generally not useful (only apply to errors/warnings) but was inherited from Support.
Some adjustment to the canonical forms
(usually from GNU readelf; currently llvm-readobj has too many redundant aliases):
* --dyn-syms is canonical. --dyn-symbols is a hidden alias
* --file-header is canonical. --file-headers is a hidden alias
* --histogram is canonical. --elf-hash-histogram is a hidden alias
* --relocs is canonical. --relocations is a hidden alias
* --section-groups is canonical. --elf-section-groups is a hidden alias
OptTable avoids global option collision if we decide to support multiplexing for binary utilities.
* Most one-dash long options are still supported. `-dt, -sd, -st, -sr` are dropped due to their conflict with grouped short options.
* `--section-mapping=false` (D57365) is strange but is kept for now.
* Many `cl::opt` variables were unnecessarily external. I added `static` whenever appropriate.
Reviewed By: jhenderson
Differential Revision: https://reviews.llvm.org/D105532
Part of https://lists.llvm.org/pipermail/llvm-dev/2021-July/151622.html
"Binary utilities: switch command line parsing from llvm::cl to OptTable"
* `--totals=false` and `--totals=0` cannot be used. Omit the option.
* `--help-list` is removed. This is a `cl::` specific option.
OptTable avoids global option collision if we decide to support multiplexing for binary utilities.
Note: because the tool is simple, and its long options are uncommon, I just drop
the one-dash forms except `-arch <value>` (Darwin style).
Reviewed By: jhenderson
Differential Revision: https://reviews.llvm.org/D105598
Similar to D104889. The tool is very simple and its long options are uncommon,
so just drop the one-dash form in this patch.
Reviewed By: jhenderson
Differential Revision: https://reviews.llvm.org/D105605
Part of https://lists.llvm.org/pipermail/llvm-dev/2021-July/151622.html
"Binary utilities: switch command line parsing from llvm::cl to OptTable"
Users should generally observe no difference as long as they only use intended
option forms. Behavior changes:
* `-t=d` is removed. Use `-t d` instead.
* `--demangle=0` cannot be used. Omit the option or use `--no-demangle` instead.
* `--help-list` is removed. This is a `cl::` specific option.
Note:
* `-t` diagnostic gets improved.
* This patch avoids cl::opt collision if we decide to support multiplexing for binary utilities
* One-dash long options are still supported.
* The `-s` collision (`-s segment section` for Mach-O) is unfortunate. `-s` means `--print-armap` in GNU nm.
* This patch removes the last `cl::multi_val` use case from the `llvm/lib/Support/CommandLine.cpp` library
`-M` (`--print-armap`), `-U` (`--defined-only`), and `-W` (`--no-weak`)
are now deprecated. They could conflict with future GNU nm options.
(--print-armap has an existing alias -s, so GNU will unlikely add a new one.
--no-weak (not in GNU nm) is rarely used anyway.)
`--just-symbol-name` is now deprecated in favor of
`--format=just-symbols` and `-j`.
Reviewed By: jhenderson
Differential Revision: https://reviews.llvm.org/D105330
There were some missing bazel dependencies for the Tosa dialect.
Added these deps.
Reviewed By: GMNGeoffrey
Differential Revision: https://reviews.llvm.org/D105326
This patch introduces a custom rule for expanding the LLVM target
enumeration .def files. This provides a slightly cleaner API for these
rules, but is mostly to permit selects to be used when determining which
LLVM targets to build. Right now the target list is generated at Bazel
configure time, but this will allows us to add functionality to also
control which targets are built based on config settings.
Tested: Ran `bazel test --config=rbe ... @llvm-project//...`
Reviewed By: chandlerc
Differential Revision: https://reviews.llvm.org/D104969
* Previously, we were only generating .h.inc files. We foresee the need to also generate implementations and this is a step towards that.
* Discussed in https://llvm.discourse.group/t/generating-cpp-inc-files-for-dialects/3732/2
* Deviates from the discussion above by generating a default constructor in the .cpp.inc file (and adding a tablegen bit that disables this in case if this is user provided).
* Generating the destructor started as a way to flush out the missing includes (produces a link error), but it is a strict improvement on its own that is worth doing (i.e. by emitting key methods in the .cpp file, we root vtables in one translation unit, which is a non-controversial improvement).
Differential Revision: https://reviews.llvm.org/D105070
I didn't realise this message was also posted to the phabricator review.
Just say "the user's local path". "local" is the important part,
the username is not important.
959eec1fdd changed the message
to show the local username with "$user" but this is not always set.
Some systems will have USER/USERNAME/LOGNAME, so just use "whoami"
instead.
This avoids diffs being applied in the work tree to files that are
supposed to be excluded (clang tests), allows arc to properly provide
interactive feedback for the formatting fixes, and reduces the number of
files that we format, in a change affecting N files, from N^2 to N.
Summary:
The only guarantee there seems to be in the clang-format packaging is
that an executable called `clang-format` is in the PATH. Use the
in-tree `clang-format-diff.py` to avoid assuming anything else.
Also remove dead code for SVN repo and switch to `git diff-index` which
is the git plumbing equivalent of `git diff` in this case.
Reviewers: starsid, mehdi_amini, vitalybuka, fhahn, kadircet
Subscribers: llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D77428
Geoffrey Martin-Noble