Both the pattern for finding the clang version metadata, and the emitted
checker, are now more robust, to handle a vendor prefix.
Differential Revision: https://reviews.llvm.org/D154520
This prevents update_cc_tests.py from emitting hard-coded identifiers
for metadata (global variable checkers still check hard-coded
identifiers). Instead it emits regex checkers that match even if the
identifiers change. Also adds a new mode for --check-globals: instead of
simply being on or off, it now has the options 'none', 'smart' and
'all', with 'none' and 'all' corresponding to the previous modes.
The 'smart' mode only emits checks for global definitions referenced
in the IR or other metadata that itself has a definition checker
emitted, making the rule transitive. It does not emit checks for
attribute sets, since that is better checked by --check-attributes. This
mode is made the new default. To make the change in default mode
backwards compatible a version bump is introduced (to v3), and the
default remains 'none' in v1 & v2.
This will result in metadata checks being emitted more often, so filters
are added to not check absolute file paths and compiler version git
hashes.
rdar://105239218
D135579 added support for fixedStack, but did not cope with the output
of -simplify-mir which does not include the fixedStack section by
default.
Differential Revision: https://reviews.llvm.org/D152896
Consider only targets where `MCAsmInfo::ExceptionsType == ExceptionHandling::None`
and that support CFI (when `MCAsmInfo::UsesCFIForDebug` is set to true):
currently, only AMDGPU.
This patch enables the emission of CFI information in the .eh_frame
section when the uwtable attribute is present on a function.
Before, we could generate CFI information for debugging puproses only.
This patch prepares AMDGPU to support collecting GPU stack traces in the future.
I did a first implementation (https://reviews.llvm.org/D139024)
but at the time I had not realized that no other platform used
`UsesCFIForDebug`.
Reviewed By: scott.linder
Differential Revision: https://reviews.llvm.org/D151806
Derive the mustprogress attribute based on the willreturn attribute
or the fact that all callers are mustprogress.
Differential Revision: https://reviews.llvm.org/D94740
This is a follow-up to b71edfaa4ec3c998aadb35255ce2f60bba2940b0
since I forgot the lit.local.cfg files in that one.
Reformatting is done with `black`.
If you end up having problems merging this commit because you
have made changes to a python file, the best way to handle that
is to run git checkout --ours <yourfile> and then reformat it
with black.
If you run into any problems, post to discourse about it and
we will try to help.
RFC Thread below:
https://discourse.llvm.org/t/rfc-document-and-standardize-python-code-style
Reviewed By: barannikov88, kwk
Differential Revision: https://reviews.llvm.org/D150762
Implement emission of DWARF CFI instructions for MSP430. This includes descriptions of stack frame layout and location of callee-saved registers that could be used for backtracing.
Differential Revision: https://reviews.llvm.org/D146966
Integrate the BranchRelaxation pass to help with relaxing out-of-range
conditional branches.
This is mostly of concern for SPARCv9, which uses conditional branches with
much smaller range than its v8 counterparts.
(Some large autogenerated code, such as the ones generated by TableGen, already
hits this limitation when building in Release)
Reviewed By: arsenm
Differential Revision: https://reviews.llvm.org/D142458
This patch enables --function-signature by default under --version 2
and makes --version 2 the default. This means that all newly created
tests will check the function signature, while leaving old tests alone.
There's two motivations for this change:
* Without --function-signature, the generated check lines may fail
in a very hard to understand way if the test both includes a
function definition and a call to that function. (Though we could
address this by making the CHECK-LABEL stricter, without checking
the full signature.)
* This actually checks that uses of the arguments in the function
body use the correct argument, instead of matching against any
variable.
This is a replacement for D139006 and D140212 based on the
--version mechanism.
I did not include an opt-out flag --no-function-signature because
I'm not sure we need it. Would be happy to include it though,
if desired.
Differential Revision: https://reviews.llvm.org/D145149
We have a number of pending changes to update_test_checks.py
(and friends) that are essentially blocked on test churn:
If the output of UTC for an existing flag combination changes,
then the next time a test is regenerated, it will contain many
spurious changes. This makes changes to UTC default
behavior essentially impossible.
Examples of such changes are:
* D133943/D142373 want --function-signature to also check the
return type/attributes.
* D139006/D140212 want to make --function-signature the default
behavior.
* D142452 wants to add wildcards for block labels.
This patch tries to resolve this issue by adding a --version
argument, which works as follows:
* When regenerating an old test, the default version is 1.
* When generating a new test, the default version is the newest.
When an explicit version is specified, that of course wins.
This means that any currently existing tests will keep using
--version 1 format, while any new tests will automatically embed
--version N where N is the latest version, and then keep using
that test format from then on.
This patch only implements the --version flag without bumping
the default version, so it does not have any visible behavior
change by itself.
Differential Revision: https://reviews.llvm.org/D142473
Materialize zeros by copying from %g0, which is now marked as constant.
This makes it possible for some common operations (like integer negation) to be
performed in fewer instructions.
This continues @arichardson's patch at D132561.
Reviewed By: arsenm
Differential Revision: https://reviews.llvm.org/D138887
This reverts commit a888825aeef8d6592c6cf5f4e5854cc39af49633.
This changes the default output of UTC, and as such introduces
spurious changes whenever existing tests are regenerated.
I've indicated in https://reviews.llvm.org/D139006#3989954 how
this can be implemented without causing test churn.
Previously, the label also matched function calls with the function
name, which caused tests to fail because the label matched on the wrong
line.
Add the `define` prefix, so only function defines are matched.
Differential Revision: https://reviews.llvm.org/D139006
As a reminder, UTC_ARGS is used by lit test cases to specify which
arguments need to be passed to update_XXXX_test_checks.py to be
auto-updated properly.
The support is achieved by relying on common.itertests, which is what
other test
updaters use to iterate over test files.
This commit also changes how the --llc-binary option is saved in args.
It used to be saved as "llc", but it is here changed to the standard
"llc_binary" to make use of an existing ignore mechanism for specific
arguments. Without that change, the option would not be ignored and
would appear in UTC_ARGS. This would be different from what e.g.
update_llc_test_checks does. As update_mir_test_checks.py now supports
UTC_ARGS, it became important to ensure the option is ignored.
Differential Revision: https://reviews.llvm.org/D135580
Over the past day or so, i've took a large swing at our tests,
and reduced the number of tests that were still using the old syntax
from ~1800 to just 200.
Left to handle: (as it is seen in this patch)
* Transforms/LSR
* Transforms/CGP
* Transforms/TypePromotion
* Transforms/HardwareLoops
* Analysis/*
* some misc.
I think this is the right point to start actively refusing
to honor the old syntax, except for the old tests,
to prevent the old syntax from creeping back in.
Thus, let's add temporary default-off flag,
and if it is not passed refuse to accept old syntax.
The tests that still need porting are annotated with this flag.
Reviewed By: aeubanks
Differential Revision: https://reviews.llvm.org/D139647
Generation of CHECK lines for fixedStack can be enabled with --print-fixed-stack.
This is particularly useful for tests which need to inspect how the
stack looks, e.g. for ABI tests.
See the other stacked revision building on top of this one which enables UTC_ARGS (in a similar fashion to other test updaters in utils/).
Reviewed By: arsenm
Differential Revision: https://reviews.llvm.org/D135579
Materialize zeros by copying from %g0, which is now marked as constant.
This makes it possible for some common operations (like integer negation) to be
performed in fewer instructions.
This continues @arichardson's patch at D132561.
Reviewed By: arsenm
Differential Revision: https://reviews.llvm.org/D138887
When the branch target is out of the range represented by the current
branch instruction's immediate, branch relaxation is required. There
are three types of immediate for branch instructions on LoongArch,
including simm16, simm21 and simm26. And the real branch target
address is PC + sext(simmXX << 2). In addition, the indirect branch
way is implemented to support larger branch target.
BranchRelaxation pass calls `RenumberBlocks` to renumber all of the
machine basic blocks in the function. So the machine basic blocks
number changed in some test cases.
Differential Revision: https://reviews.llvm.org/D137233
This switches everything to use the memory attribute proposed in
https://discourse.llvm.org/t/rfc-unify-memory-effect-attributes/65579.
The old argmemonly, inaccessiblememonly and inaccessiblemem_or_argmemonly
attributes are dropped. The readnone, readonly and writeonly attributes
are restricted to parameters only.
The old attributes are auto-upgraded both in bitcode and IR.
The bitcode upgrade is a policy requirement that has to be retained
indefinitely. The IR upgrade is mainly there so it's not necessary
to update all tests using memory attributes in this patch, which
is already large enough. We could drop that part after migrating
tests, or retain it longer term, to make it easier to import IR
from older LLVM versions.
High-level Function/CallBase APIs like doesNotAccessMemory() or
setDoesNotAccessMemory() are mapped transparently to the memory
attribute. Code that directly manipulates attributes (e.g. via
AttributeList) on the other hand needs to switch to working with
the memory attribute instead.
Differential Revision: https://reviews.llvm.org/D135780
We have a downstream project with a command-line utility that operates
pretty much exactly like `opt`. So it would make sense for us to
maintain tests with update_test_checks.py with our custom tool
substituted for `opt`, as this change allows.
Differential Revision: https://reviews.llvm.org/D136329
Some instructions are not matched by update_mir_test_checks.py because MIFlags and
regex in the script are not synchronized.
Differential Revision: https://reviews.llvm.org/D136170
Functions with `aarch64_sme_pstatesm_body` will emit a SMSTART at the start
of the function, and a SMSTOP at the end of the function, such that all
operations use the right value for vscale.
Because the placement of these nodes is critically important (i.e. no
vscale-dependent operations should be done before SMSTART has been issued),
we require glueing the CopyFromReg to the Entry node such that we can
insert the SMSTART as part of that glued chain.
More details about the SME attributes and design can be found
in D131562.
Reviewed By: aemerson
Differential Revision: https://reviews.llvm.org/D131582
While this does not matter for most targets, when building for Arm Morello,
we have to mark the symbol as a function and add size information, so that
LLD can correctly evaluate relocations against the local symbol.
Since Morello is an out-of-tree target, I tried to reproduce this with
in-tree backends and with the previous reviews applied this results in
a noticeable difference when targeting Thumb.
Background: Morello uses a method similar Thumb where the encoding mode is
specified in the LSB of the symbol. If we don't mark the target as a
function, the relocation will not have the LSB set and calls will end up
using the wrong encoding mode (which will almost certainly crash).
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D131429
While working on https://reviews.llvm.org/D131429, I got a test diff in
one of the VE tests and running update_llc_test_checks.py deleted all the
code for that function. This updates the regex to handle this new output.
Reviewed By: kaz7
Differential Revision: https://reviews.llvm.org/D131431
While working on https://reviews.llvm.org/D131429, I got a test diff in
one of the VE tests and running update_llc_test_checks.py deleted all the
code for that function. This is a baseline test for this bug (incorrect
regex for VE when .Lfoo$local symbols are used).
Reviewed By: kaz7
Differential Revision: https://reviews.llvm.org/D131434
This patch only add %pc_hi20/%pc_lo12/%plt relocations in order
to be able to generate gnu ld linkable relocation file for the
`hello world` IR :
```
@.str = private unnamed_addr constant [14 x i8] c"Hello world!\0A\00", align 1
define dso_local signext i32 @main() nounwind {
entry:
%call = call signext i32 (ptr, ...) @printf(ptr noundef @.str)
ret i32 0
}
declare dso_local signext i32 @printf(ptr noundef, ...)
```
This patch also updates some test cases due to new modifiers introduced.
New test: test/MC/LoongArch/Relocations/relocations.s
Differential Revision: https://reviews.llvm.org/D132108
This allows a number of optimisation passes to work.
E.g. BranchFolding and MachineBlockPlacement.
Differential Revision: https://reviews.llvm.org/D131316
There is at least one Clang test (clang/test/CodeGen/arm_acle.c) which
has functions guarded by #if's that cause those functions to be compiled
only for a subset of RUN lines.
This results in a case where one RUN line has a body for the function
and another doesn't. Treat this case as a conflict for any prefixes that
the two RUN lines have in common.
This change exposed a bug where functions with '$' in the name weren't
properly recognized in ARM assembly (despite there being a test case
that was supposed to catch the problem!). This bug is fixed as well.
Differential Revision: https://reviews.llvm.org/D130089
The first attempt missed changing test files for tools
(update_llc_test_checks.py).
Original commit message:
This implements the main suggested change from issue #56498.
Using the shorter (non-extending) instruction with only
-Oz ("minsize") rather than -Os ("optsize") is left as a
possible follow-up.
As noted in the bug report, the zero-extending load may have
shorter latency/better throughput across a wide range of x86
micro-arches, and it avoids a potential false dependency.
The cost is an extra instruction byte.
This could cause perf ups and downs from secondary effects,
but I don't think it is possible to account for those in
advance, and that will likely also depend on exact micro-arch.
This does bring LLVM x86 codegen more in line with existing
gcc codegen, so if problems are exposed they are more likely
to occur for both compilers.
Differential Revision: https://reviews.llvm.org/D129775
Add LoongArch assembly scrubbing and triple support to update_llc_test_checks.
Depends on D128432
Reviewed By: MaskRay, xen0n
Differential Revision: https://reviews.llvm.org/D128433
When we appended check lines at the end we could not share prefixes
before. This patch should make it possible and allow us to reduce
some check line counts (especially for Clang/OpenMP tests).
See also: https://reviews.llvm.org/D128686
Differential Revision: https://reviews.llvm.org/D128684
Use the query that doesn't assert if TracksLiveness isn't set, which
needs to always be available. We also need to start printing liveins
regardless of TracksLiveness.
Support the pattern where a test file uses multiple prefixes per run line:
one prefix that is unique to the run line, and additional prefixes that are
common with other run lines.
Decide on a per-function basis which prefix(es) to emit, based on which run
lines have the same output.
Move the renaming of vregs earlier, so that we can compare the output as it
would actually be printed in check lines.
Differential Revision: https://reviews.llvm.org/D126411
