This should convert the type set for each HwMode to an MVT for that
HwMode. Instead, if a single type existed for the DefaultMode, that was
used for the MVT of every other mode.
This didn't cause an issue because there is only one place this function
is used before HwModes are expanded. That's just verifying that
constants are small enough for the MVT for each mode. So you would need
a large constant and a HwMode with a smaller VT than the default mode.
Having duplicate mode entries previously asserted (or silently replaced
the last value with a new one in release builds). Report an error with
a helpful message instead.
Pull Request: https://github.com/llvm/llvm-project/pull/171715
Previously we would assert when a ValueTypeByHwMode was missing a case
for the current mode, now we report an error instead. Interestingly this
error only ocurrs when the DAG patterns use RegClassByHwMode, but not
normal RegisterClass instances. Found while I added RegClassByHwMode
to RISC-V and was getting an assertion due to `XLenFVT`/`XLenVecI32VT`
not having an entry for the default mode.
Reviewed By: arsenm
Pull Request: https://github.com/llvm/llvm-project/pull/171254
This is a generalization of the LookupPtrRegClass mechanism.
AMDGPU has several use cases for swapping the register class of
instruction operands based on the subtarget, but none of them
really fit into the box of being pointer-like.
The current system requires manual management of an arbitrary integer
ID. For the AMDGPU use case, this would end up being around 40 new
entries to manage.
This just introduces the base infrastructure. I have ports of all
the target specific usage of PointerLikeRegClass ready.
This is needed to provide proper size and offset for the GPRPair subreg
indices on RISC-V. The size of a GPR already uses HwMode. Previously we
said the subreg indices have unknown size and offset, but this stops
DwarfExpression::addMachineReg from being able to find the registers
that make up the pair.
I believe this fixes https://github.com/llvm/llvm-project/issues/85864
but need to verify.
Refactor of the llvm-tblgen source into:
- a "Basic" library, which contains the bare minimum utilities to build
`llvm-min-tablegen`
- a "Common" library which contains all of the helpers for TableGen
backends. Such helpers can be shared by more than one backend, and even
unit tested (e.g. CodeExpander is, maybe we can add more over time)
Fixes#80647
