Hexagon instructions are VLIW "bundles" of up to four instruction words
encoded as a single MCInst with operands for each sub-instruction.
Previously, the disassembler's getInstruction() returned the full
bundle, which made it difficult to work with llvm-objdump.
For example, since all instructions are bundles, and bundles do not
branch, branch targets could not be printed.
This patch modifies the Hexagon disassembler to return individual
sub-instructions instead of entire bundles, enabling correct printing of
branch targets and relocations. It also introduces
`MCDisassembler::getInstructionBundle` for cases where the full bundle
is still needed.
By default, llvm-objdump separates instructions with newlines. However,
this does not work well for Hexagon syntax:
{ inst1
inst2
inst3
inst4 <branch> } :endloop0
Instructions may be followed by a closing brace, a closing brace with
`:endloop`, or a newline. Branches must appear within the braces.
To address this, `PrettyPrinter::getInstructionSeparator()` is added and
overridden for Hexagon.
Windows Itanium and PS5 are both Itanium C++ ABI variants which have the
goal of semantic compatibility with Microsoft C++ code that uses
dllimport/export.
This patch adds Windows Itanium and PS5 triple testing to
clang/test/Sema/dllexport.c. We have this testing in our downstream
toolchain - for some reason it was not added upstream when the work for
supporting dllimport/export was done.
We should ignore uses of pointers in lifetime intrinsics, as these are
not actually materialized in the final code, so don't affect register
pressure or anything else LSR needs to model.
Handling these only results in peculiar rewrites where additional
intermediate GEPs are introduced.
Currently the pull_request event on the build CI container workflows are
restricted to main. This prevents building them on stacked PRs. This is
a bit annoying because we do not get the CI to test that everything is
working until all of the base PRs have landed and the target branch
becomes main.
Currently, AsmPrinter skips CFI instructions created by a backend if
they are not needed. I'd like to change that so that it always
prints/encodes CFI instructions if a backend created them.
This change should slightly (perhaps negligibly) improve compile time as
post-PEI passes no longer need to skip over these instructions in
no-exceptions no-debug builds, and will allow to simplify convoluted
logic in AsmPrinter once other targets stop emitting CFI instructions
when they are not needed (that's my final goal).
The changes in a test seem to be caused by slightly different post-RA
scheduling in the absence of CFI instructions.
The only place that passes a target to `LoadAddressResolver` already
checks for pointer validity. And inside of the resolver we have been
dereferencing the target anyway without nullptr checks. So codify the
non-nullness of `m_target` by making it a reference.
This is another prune of dead code -- we never generate debug intrinsics
nowadays, therefore there's no need for these codepaths to run.
---------
Co-authored-by: Nikita Popov <github@npopov.com>
Let Clang emit `dead_on_return` attribute on pointer arguments
that are passed indirectly, namely, large aggregates that the
ABI mandates be passed by value; thus, the parameter is destroyed
within the callee. Writes to such arguments are not observable by
the caller after the callee returns.
This should desirably enable further MemCpyOpt/DSE optimizations.
Previous discussion: https://discourse.llvm.org/t/rfc-add-dead-on-return-attribute/86871.
For mutable and const fields, we have two bits in InlineDescriptor,
which both get inherited down the hierarchy. When a field is both const
and mutable, we CAN read from it if it is a mutable-in-const field, but
we _can't_ read from it if it is a const-in-mutable field. We need
another bit to distinguish the two cases.
There are a few duplicate paths/facilities in the coroutine code to deal
with both intrinsics and debug-records; we can now delete the intrinsic
version.
If a multilib collection contains libraries built for different methods
of accessing global data (via absolute address, or via a GOT in -fPIC
style, or as an offset from a fixed register in Arm -frwpi style), then
`multilib.yaml` will need to know which relocation model an application
is using in order to select the right library.
Even if a multilib collection only supports one relocation model, it's
still useful for `multilib.yaml` to be able to tell if the user has
selected the right one, so as to give a useful error message if they
haven't, instead of silently selecting a library that won't work.
In this commit we determine the PIC / ROPI / RWPI status using the
existing logic in `ParsePICArgs`, and translate it back into a canonical
set of multilib selection flags.
https://github.com/llvm/llvm-project/pull/149282 changed
the max children depth and that caused one part of the
output to become `{...}`.
The original PR set a higher limit for a different test,
so I'm doing the same here.
