[Comgr][hotswap] Add DecodedInst + basic kernel decoder

[tgymnich]

Wraps the MC-layer disassembler in a hotswap-shaped API:

• decoded_inst.h — DecodedInst value type bundling MCInst, raw bytes, kernel offset, TSFlags, and an explicit IsBranch / BranchTarget decoration so Phase-3 BB layout can run without re-querying MCInstrDesc.
• parsed_reg.h — ParsedReg{Kind, BaseIdx, NReg} value type so handlers can match on register class without re-parsing MCOperand::getReg() at every consumer.
• decode.{h,cpp} — decodeKernel walks the .text section once, populates a DecodeResult{Insts, BlockStarts, Offsets} view used by every subsequent raise phase. Block boundaries derive from the branch target set discovered during the linear sweep so Phase 3 can pre-create LLVM BasicBlocks before any IR builder lands.
• mc_state.cpp — minor reshuffle to expose the MCDisassembler / MCSubtargetInfo pair to the new decode entry point.

[tgymnich]

Warning

Stacked PR

1. [Comgr][hotswap] Add bare-bones hotswap transpiler scaffolding #2438
2. [Comgr][hotswap] Add code-object metadata parsing #2437
3. [Comgr][hotswap] Add AMDGPU MC state setup #2439
4. [Comgr][hotswap] Add DecodedInst + basic kernel decoder #2517 <----
5. [Comgr][hotswap] Add wave projection + ISA profile + abi/wave-mask docs #2518
6. [Comgr][hotswap] Add raise_failure + RaiseContext + register file #2551
7. [Comgr][hotswap] Add raise_cli + lit harness for hotswap-raise fixtures #2552
8. [Comgr][hotswap] Add SOPP + SOPC handlers #2553

[ftynse]

Overall, the DecodedInst data structure looks needlessly fat and redundant. A lot of its fields are duplicating information from MCInst, which it also stores, and should be converted into accessor functions. Some flags are relevant for any instruction with a specific name/class, not a particular instance, so there is no value in storing them per-instance except micro-optimization on the hot path (that would require data prior to implementing them). Even when it's a hot path, a plausible solution would be to have a look-aside table with that information and store pointers into that table instead.

There are also comments about string parsing, though I don't really see any code performing, and would complain about it unless the approach is unavoidable. The only place with string parsing seems to be vcmp that I already complained about in the previous PR.

[ftynse]

Suggested change

	}
	namespace COMGR::hotswap {

[ftynse]

This needs a doc. All of the fields need doc.

[ftynse]

Nit: add a comment saying which #if this closes.

[ftynse]

Do we really need to store the textual mnemonic, twice? For every instance of an instruction. Can't we rather have an enum entry and/or the opcode. It also looks like we have the MCInst below, so this may even be redundant.

[ftynse]

If we really need to store textual representation of the instruction for some reason, as opposed to generating it on-the-fly from MCInt, maybe we can generate full textual assembly once into a memory mapped file or something like that and only store pointers/StringRefs to that instead of piecemeal dynamic allocations of strings for every instance.

[ftynse]

SmallString to avoid dynamic allocations.

[ftynse]

See comment above about printing the whole function and keeping references instead, assuming this is needed at all.

[ftynse]

Can't this be done on the fly?

[ftynse]

Perhaps we want to signal how many bytes we processed if it's not the whole input.

[ftynse]

So we are storing 48*4=192 bytes of information per instruction here where the overwhelming majority of instructions won't ever use 24 sources. Sounds ridiculously wasteful. Just use a SmallVector.

[ftynse]

A separate question is testing. We need a way to test this as well.