[PATCH] D84519: [llvm-objdump][AMDGPU] Detect subtarget

Tue Jul 28 08:15:49 PDT 2020

arsenm added a comment.

In D84519#2178859 <https://reviews.llvm.org/D84519#2178859>, @scott.linder wrote:

> In D84519#2177164 <https://reviews.llvm.org/D84519#2177164>, @MaskRay wrote:
>
>> In D84519#2176909 <https://reviews.llvm.org/D84519#2176909>, @scott.linder wrote:
>>
>>> In D84519#2174866 <https://reviews.llvm.org/D84519#2174866>, @MaskRay wrote:
>>>
>>>> Can we step back and think whether precise CPU selection is really necessary? For example, PowerPC has the needs for different ISA levels but it simply uses -mcpu=future.
>>>
>>> I am a bit lost on what you mean; is there a significant cost to providing precise CPU selection? It doesn't make sense to require the user to e.g. run the dumper to inspect the binary in order to come up with the command-line to run the dumper in order to inspect the binary.
>>
>> -mcpu=pwr10 decodes more instructions than -mcpu=pwr9.
>> -mcpu=pwr9 decodes more instructions than -mcpu=pwr8.
>>
>> I think GNU objdump just decodes all instructions it recognizes, not expecting a -mcpu option. It behaves as if the default recognized ISA level includes everything.
>
> Ah, that makes sense. For AMDGCN your earlier point (and Eric's point in email, which doesn't seem to have made it here) concerning incompatibility applies: we don't have forward or backward compatibility between ISA generations. Essentially any change to mcpu (and some features, IIUC) can make two ISAs fundamentally incompatible. I think we have attempted to approximate a "default" ISA before for things like disassembly and failed.

For example in one minor revision, the interpretation of an opcode was changed so we have to change the name in the disassembly based on the individual feature

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D84519/new/

https://reviews.llvm.org/D84519