Simplifies the implementation of `TypeSize` while retaining its interface.
There is no need for abstract concepts like `LinearPolyBase`, `UnivariateLinearPolyBase` or `LinearPolySize`.
Differential Revision: https://reviews.llvm.org/D140263
Simplifies the implementation of `TypeSize` while retaining its interface.
There is no need for abstract concepts like `LinearPolyBase`, `UnivariateLinearPolyBase` or `LinearPolySize`.
Differential Revision: https://reviews.llvm.org/D140263
Use deduction guides instead of helper functions.
The only non-automatic changes have been:
1. ArrayRef(some_uint8_pointer, 0) needs to be changed into ArrayRef(some_uint8_pointer, (size_t)0) to avoid an ambiguous call with ArrayRef((uint8_t*), (uint8_t*))
2. CVSymbol sym(makeArrayRef(symStorage)); needed to be rewritten as CVSymbol sym{ArrayRef(symStorage)}; otherwise the compiler is confused and thinks we have a (bad) function prototype. There was a few similar situation across the codebase.
3. ADL doesn't seem to work the same for deduction-guides and functions, so at some point the llvm namespace must be explicitly stated.
4. The "reference mode" of makeArrayRef(ArrayRef<T> &) that acts as no-op is not supported (a constructor cannot achieve that).
Per reviewers' comment, some useless makeArrayRef have been removed in the process.
This is a follow-up to https://reviews.llvm.org/D140896 that introduced
the deduction guides.
Differential Revision: https://reviews.llvm.org/D140955
Revert "Fix lldb option handling since e953ae5bbc (part 2)"
Revert "Fix lldb option handling since e953ae5bbc313fd0cc980ce021d487e5b5199ea4"
GCC build hangs on this bot https://lab.llvm.org/buildbot/#/builders/37/builds/19104
compiling CMakeFiles/obj.clangBasic.dir/Targets/AArch64.cpp.d
The bot uses GNU 11.3.0, but I can reproduce locally with gcc (Debian 12.2.0-3) 12.2.0.
This reverts commit caa713559b.
This reverts commit 06b90e2e9c.
This reverts commit e953ae5bbc.
Allow targets to define a mapping from registers to register
classes such that each register has exactly one base class.
As registers may be in multiple register classes the base class
is determined by the container class with the lowest BaseClassOrder.
Only register classes with BaseClassOrder set are considered
when determining the base classes. By default BaseClassOrder is
unset in RegisterClass so no code is generated unless a target
explicit defines one or more base register classes.
Reviewed By: arsenm, foad
Differential Revision: https://reviews.llvm.org/D139616
value() has undesired exception checking semantics and calls
__throw_bad_optional_access in libc++. Moreover, the API is unavailable without
_LIBCPP_NO_EXCEPTIONS on older Mach-O platforms (see
_LIBCPP_AVAILABILITY_BAD_OPTIONAL_ACCESS).
This commit fixes LLVMAnalysis and its dependencies.
It is generally good practice, if you know how big the vector is going to be in the end, to reserve before continually calling "push_back" or "emplace_back"
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D139483
Commit a538d1f13a first added support for named sub-operands in
CodeEmitterGen. We now add a few more features to that, enabling
further target cleanups.
1. Adds support for handling an EncoderMethod in a sub-operand in
CodeEmitterGen. Previously, the specified encoder of a sub-operand was
ignored, and only the default used.
2. Adds support for sub-operands in DecoderEmitter, along with support
for tied sub-operands.
The changes to the decoder required a few minor tweaks to a few
targets, where existing brokeness was exposed. In order to keep this
patch small, I left FIXMEs which will be addressed in upcoming
patches. (Except MIPS16, since its object file emission/decoding is
totally broken).
Differential Revision: https://reviews.llvm.org/D137653
llvm/tools/llvm-objdump/llvm-objdump.cpp:128:38: error: constexpr variable 'ObjdumpInfoTable' must be initialized by a constant expression
static constexpr opt::OptTable::Info ObjdumpInfoTable[] = {
^ ~
ObjdumpOpts.inc:30:45: note: non-constexpr function 'substr' cannot be used in a constant expression
OPTION(prefix_0, llvm::StringRef("<input>").substr(0), INPUT, Input, INVALID, INVALID, nullptr, 0, 0, nullptr, nullptr, nullptr)
^
This patch mechanically replaces None with std::nullopt where the
compiler would warn if None were deprecated. The intent is to reduce
the amount of manual work required in migrating from Optional to
std::optional.
This is part of an effort to migrate from
llvm::Optional to std::optional:
https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
Eliminates the need for working around optional and token operands being
mistakenly parsed as expressions.
Reviewed By: dp
Differential Revision: https://reviews.llvm.org/D138492
Marking rs1 (memory offset base) as memory operand provides additional
semantic value to this operand that can be used by different tools
(e.g. llvm-exegesis).
This change does not affect neigther Isel nor assembler. However it
required some tweaks in tablegen compressed inst emmiter.
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D136847
When calculating the size of concatenated subregisters, and at least
one of the subregisters involved has an unknown size (-1), then the
concatenated size should be set to -1 as well.
This bug was found for an out-of-tree target.
Looking at lib/Target the only in-tree target that has a subregister
with unknown size is X86:
X86RegisterInfo.td: def sub_mask_0 : SubRegIndex<-1>;
But it looks like sub_mask_0 don't result in any concatenated subreg
index with faulty size if looking at X86SubRegIdxRanges[].
Differential Revision: https://reviews.llvm.org/D138341
This patch adds dumping of the Offset and Size info for each
SubRegIndex printed when using
llvm-tblgen -gen-register-info -register-info-debug
It also updates the ConcatenatedSubregs.td to check those printouts,
including some new subreg definitions that show short-comings in
how the size is calculated when concatenating subregisters and at
least one has an incomplete size (-1). Today TableGen will just add
sizes together, resulting in MCRegisterInfo::getSubRegIdxSize()
returning a value that isn't -1 even if the combined subregister size
is unknown.
Differential Revision: https://reviews.llvm.org/D138340
The TableGen implementation was using a homegrown implementation of
FunctionModRefInfo. This switches it to use MemoryEffects instead.
This makes the code simpler, and will allow exposing the full
representational power of MemoryEffects in the future. Among other
things, this will allow us to map IntrHasSideEffects to an
inaccessiblemem readwrite, rather than just ignoring it entirely
in most cases.
To avoid layering issues, this moves the ModRef.h header from IR
to Support, so that it can be included in the TableGen layer.
Differential Revision: https://reviews.llvm.org/D137641
Currently, the asm parser stops matching instruction operands as soon as
the first optional operand is encountered. This leads to the need for
custom checks on missing mandatory operands that come after optional
operands.
The patch changes the parser to always match all optional and mandatory
instruction operands, thus making the custom checks unnecessary. This is
particularly useful for the AMDGPU backend where we have numerous
optional instruction modifiers.
Differential Revision: https://reviews.llvm.org/D137549
Currently, the asm parser stops matching instruction operands as soon as the first optional operand is encountered. This leads to the need for custom checks on missing mandatory operands that come after optional operands.
The patch changes the parser to always match all optional and mandatory instruction operands, thus making the custom checks unnecessary. This is particularly useful for the AMDGPU backend where we have numerous optional instruction modifiers.
Reviewed By: dp
Differential Revision: https://reviews.llvm.org/D137549
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
