sync_source_lists_from_cmake.py checks that every unittest in CMake
also exists in the GN build. 7b08b4360b48 added SPRIVTests, but the GN
build doesn't include the SPIRV target. So add a dummy target for this
to placate the check.
See also VETests in the gn build, which has the same setup.
This reverts commit bc06cd5cbcfc22dd976f6742d10bc934e1353b8a.
This caused the job to fail for PRs which still had an older version
of code-format-helper.py in their tree.
Actions triggered by pull_request_target events have access to all
repository secrets, so it is unsafe to use them when executing untrusted
code. The pr-code-format workflow does not execute any untrusted code,
but it passes untrused input into clang-format. An attacker could use
this to exploit a flaw in clang-format and potentially gain access to
the repository secrets.
By splitting the workflow, we can use the pull_request target which is
more secure and isolate the issue write permissions in a separate job.
The pull_request target also makes it easier to test changes to the
code-format-helepr.py script, because the version of the script from the
pull request will be used rather than the version of the script from
main.
Fixes#77142
Deprecated since clang-tidy 17. The rule DCL21-CPP has been removed from
the CERT guidelines, so it does not make sense to keep the check.
Fixes#42788
Co-authored-by: Carlos Gálvez <carlos.galvez@zenseact.com>
This change adds a comment to the first PR from a new contributor that
is merged, which tells them what to expect post merge from the build
bots.
How they will be notified, where to ask questions, that you're more
likely to be reverted than in other projects, etc. The information
overlaps with, and links to
https://llvm.org/docs/MyFirstTypoFix.html#myfirsttypofix-issues-after-landing-your-pr.
So that users who simply read the email are still aware, and know where
to follow up if they do get reports.
To do this, I have added a hidden HTML comment to the new contributor
greeting comment. This workflow will look for that to tell if the author
of the PR was a new contributor at the time they opened the merge. It
has to be done this way because as soon as the PR is merged, they are by
GitHub's definition no longer a new contributor and I suspect that their
author association will be "contributor" instead.
I cannot 100% confirm that without a whole lot of effort and probably
breaking GitHub's terms of service, but it's fairly cheap to work around
anyway. It seems rare / almost impossible to reopen a PR in llvm at
least, but in case it does happen the buildbot info comment has its own
hidden HTML comment. If we find this we will not post another copy of
the same information.
reserveRegisterTuples is slow because it uses MCRegAliasIterator and
hence ends up reserving the same aliased registers many times. This
patch changes getReservedRegs not to use it for reserving SGPRs, VGPRs
and AGPRs. Instead it iterates through base register classes, which
should come closer to reserving each register once only.
Overall this speeds up the time to run check-llvm-codegen-amdgpu in my
Release build from 18.4 seconds to 16.9 seconds (all timings +/- 0.2).
APX promoted MOVBE instructions were supported in #77431. The reg2reg
variants of MOVBE are newly introduced by APX and can be optimized to
BSWAP instruction when the 2 register operands are same.
This patch adds manual entries for MOVBErr instructions when we do ndd
to non-ndd compression #77731.
RFC:
https://discourse.llvm.org/t/rfc-design-for-apx-feature-egpr-and-ndd-support/73031/4
- When selecting the minimal type for 'MatchClassKind' during the
emission of 'MatchEntry' and 'OperandMatchEntry', two pre-defined
kinds 'InvalidMatchClass' and 'OptionalMatchClass' are not taken into
account.
Both OPC_ExtractField and OPC_CheckField are currently defined to take
an unsigned 8-bit start value. On some architectures with long
instruction words, this value can silently overflow, resulting in a bad
decoder table.
This patch changes each to take a ULE128B-encoded start value instead.
Additionally, a range assertion is added for the 8-bit length to
prominently notify a user in case that field ever overflows.
This problem isn't currently exposed upstream since all in-tree targets
use small instruction words (i.e., bitwidth <= 64 bits). It does show up
in at least one downstream target with instructions > 64 bits long.
Co-authored-by: Jason Eckhardt <jeckhardt@nvidia.com>
Currently this test is assuming that ~/.local/bin (or wherever the
Python binaries are installed to) is on the path. This is not a valid
assumption in most cases, and it also means we might not find the
version of pytype associated with the Python interpreter being used to
test LLVM, which could create some inconsistencies. This patch fixes
that by invoking pytype through the Python interpreter passed to lit.
This patch adds a pytype test to the mlgo-utils lit test suite to
prevent regressions in typing while we wait to setup precommit CI for
this specific project.
This is somewhat hacky, but is a temporary fix and will be pulled out
soonish. It also should only impact the ML buildbots as they are the
only ones that should have `pytype` installed.
We used to support a /branch comment to specify a branch with commits to
backport to the release branch. However, now that we can use pull
requests this is not needed.
This also simplifies the process, because now the cherry-pick job can
create the pull request directly instead of having it split across two
separate jobs.
The test reaches into internal headers. Make sure generated files
are ready for that.
(This is the only place. If there were more, we should use public_deps
instead.)
This is currently broken, because the check is performed on the wrong
repository. repo here is llvm/llvm-project, which is not a fork (so this
will always trigger), then we'll push a new branch to
llvmbot/llvm-project, and then again set the wrong owner, so we'll look
for the branch in llvm/llvm-project rather than llvmbot/llvm-project.
Rather than fixing this, I'm removing the code entirely, as it shouldn't
be needed anymore (llvmbot/llvm-project is a fork of llvm/llvm-project).
3ab8d2aac7bc relanded in 3112578597c031, so reland this too.
Might want to set this to True (and add a few source files to
builtins) at some point, but for now heal the bots.
