This is an archive of the discontinued LLVM Phabricator instance.

AMDGPU: Correct reported code size
AbandonedPublic

Authored by arsenm on Apr 14 2016, 2:20 PM.

Details

Summary

For a while this has been counting many instructions as 0,
so the printed code size comment hasn't been very meaningful.

This sets the instruction size to 8 for all 64-bit instructions.
For instructions which may include an additional 4 byte literal,
it is set to 0 because the size must be determined from the operands.

This currently breaks the disassembler for all of the 4-byte
instructions which may have a literal.

Diff Detail

Event Timeline

arsenm updated this revision to Diff 53785.Apr 14 2016, 2:20 PM
arsenm retitled this revision from to AMDGPU: Correct reported code size.
arsenm updated this object.
arsenm added a subscriber: llvm-commits.
vpykhtin edited edge metadata.Apr 14 2016, 2:54 PM

Why not to consider 4 byte instructions as having potentially larger size and keep current encoding sizes?

Why not to consider 4 byte instructions as having potentially larger size and keep current encoding sizes?

It's supposed to be 0 if it can't be determined just from the opcode:

// Size - Size of encoded instruction, or zero if the size cannot be determined
// from the opcode.
int Size = 0;

I'm ok with the change but I need to find out which disassembly decoding table zero sized instructions will be placed to or is there other decoding mechanism for such instructions.

SamWot accepted this revision.Apr 25 2016, 6:08 AM
SamWot edited edge metadata.

LGTM

This revision is now accepted and ready to land.Apr 25 2016, 6:08 AM

Can you take a look at what is required to fix the disassembler with this patch?

arsenm added a comment.Jun 6 2016, 1:17 PM

I've split the function into r271936 and left the rest until the disassembler is fixed

I've split the function into r271936 and left the rest until the disassembler is fixed

can you show the diff?

Sorry, I completely forgot about this patch, I'll try to take a look what it takes to fix disasm today or tommorow.

arsenm updated this revision to Diff 60270.Jun 9 2016, 4:01 PM
arsenm edited edge metadata.

Update diff and drop already committed parts

arsenm updated this revision to Diff 62009.Jun 27 2016, 1:10 PM

Update diff

Why not to consider 4 byte instructions as having potentially larger size and keep current encoding sizes?

It's supposed to be 0 if it can't be determined just from the opcode:

// Size - Size of encoded instruction, or zero if the size cannot be determined
// from the opcode.
int Size = 0;

It turns out when Size==0 no decoding code is generated for an instruction at all. See FixedLenDecoderEmitter.cpp, line 2276. The comment above probably assumes custom decoder should be used but this is an overkill in this situation. I think we should left current sizes and fix computed len somehow differently.

arsenm added a comment.Oct 6 2016, 3:22 AM

Committed a bit more of the patch in r283437

arsenm abandoned this revision.Nov 15 2016, 12:05 PM