[PATCH] D52100: [tblgen] Allow FixedLenDecoderEmitter to use APInt-like objects as InsnType

[Daniel Sanders via Phabricator via llvm-commits]

dsanders added a comment.

I've been thinking about this over the weekend and I think I may be able to hazard a guess: Are you trying to use APInt directly? Or use APInt-like object that meets all the requirements in the emitted comment? (see emitFieldFromInstruction)

The reason I ask is that while the expected interface generally a subset of APInt, there's a few requirements that APInt itself doesn't meet. Specifically:

1. Have a static const max_size_in_bits equal to the number of bits in the encoding.
2. be constructible from a uint64_t
3. be convertible to uint64_t

>From that list 1. is to support the sanity checking asserts that ensure we don't extract more bits than we have. 2. is primarily to support the 'tmp = 0' in the generated which could be fixed if we require targets to declare their need for the APInt-like up front so we can change the code emitted for that (it's necessary for the integral case). 3. was primarily to pass it in MCOperand::CreateImm() but looking at it again, there's probably a bug lurking there as one of the messages in the flood of CreateImm-related errors involves the SoftFail checks which use decodeULEB128 which return uint64_t.


Repository:
  rL LLVM

https://reviews.llvm.org/D52100