This is an archive of the discontinued LLVM Phabricator instance.

[AMDGPU] fix readlane/readfirstlane src vgpr operand type.
ClosedPublic

Authored by vpykhtin on Apr 1 2016, 8:39 AM.

Details

Summary

For VGPR_32 operand disassembler expects a VGPR register encoded as 0..255 (enum8 src operand). readfirstlane/readline actually has enum9 operand and this change fixes VGPR_32 to VS_32 (enum9 encoding).

For me it was a surprise why the encoding works however. This happens because SIMCCodeEmitter::getMachineOpValue always returns enum9 registry encoding and it is being cut by autogenerated encoder when written to enum8 field. For example v2 has encoding value 258 in enum9 and it becomes 2 when it is being written to a enum8 field.

Diff Detail

Repository
rL LLVM

Event Timeline

vpykhtin updated this revision to Diff 52376.Apr 1 2016, 8:39 AM
vpykhtin retitled this revision from to [AMDGPU] fix readlane/readfirstlane src vgpr operand type..
vpykhtin updated this object.
vpykhtin added reviewers: tstellarAMD, arsenm.

Does the assembler support this instruction? It would be nice to have some assembler tests that check the encoding for some edge cases.

Does the assembler support this instruction? It would be nice to have some assembler tests that check the encoding for some edge cases.

Yes, it has testcases:

vop1.s
// GCN: v_readfirstlane_b32 s1, v2 ; encoding: [0x02,0x05,0x02,0x7e]
v_readfirstlane_b32 s1, v2

vop2.s
SICI: v_readlane_b32 s1, v2, s3 ; encoding: [0x02,0x07,0x02,0x02]
VI: v_readlane_b32 s1, v2, s3 ; encoding: [0x01,0x00,0x89,0xd2,0x02,0x07,0x00,0x00]
v_readlane_b32 s1, v2, s3

For other usages I hope we'll submit much more testcases soon, Dmitry Preobrazhensky is working on it.

tstellarAMD accepted this revision.Apr 5 2016, 4:51 PM
tstellarAMD edited edge metadata.

LGTM.

This revision is now accepted and ready to land.Apr 5 2016, 4:51 PM
This revision was automatically updated to reflect the committed changes.