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
D49116 was using clang-format-diff because at the time of its writing,
it needed to handle the subversion repo as well.
Differential Revision: https://reviews.llvm.org/D77363
Summary:
This uses clang-format-diff as a linter for Arcanist.
`arc lint` flow, also run as part of `arc diff` unless skipped with
`--nolint`, will now run the linter shell script on the changed files,
and prompt the user to accept the suggested changes.
Message when clang-format-diff is not installed:
{F6654094}
Example of the noise during code review when clang-format-diff is not installed:
https://reviews.llvm.org/differential/changeset/?ref=1115809
Prompt when clang-format-diff is installed and suggests edits:
{F6650223}
Reviewers: probinson, scott.linder
Reviewed By: scott.linder
Subscribers: scott.linder, MyDeveloperDay, JonasToth, danilaml, JDevlieghere, dberris, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D49116
Shivam Gupta