This is an archive of the discontinued LLVM Phabricator instance.

[AMDGPU] w/a for gfx908 mfma SrcC literal HW bug
ClosedPublic

Authored by rampitec on Aug 23 2019, 11:38 AM.

Diff Detail

Event Timeline

rampitec created this revision.Aug 23 2019, 11:38 AM

Can we have different opcodes with a different source type?

Can we have different opcodes with a different source type?

It will be a quite big change. What for?

Can we have different opcodes with a different source type?

It will be a quite big change. What for?

Generally if the operand/register class changes there should be a separate opcode. It avoids needing all this special case checking, and makes folding code work naturally

Can we have different opcodes with a different source type?

It will be a quite big change. What for?

Generally if the operand/register class changes there should be a separate opcode. It avoids needing all this special case checking, and makes folding code work naturally

Anyway, you cannot have two opcodes with the same opcode without introducing a new encoding and a new decoder namespace. This bug will be fixed.

Can we have different opcodes with a different source type?

It will be a quite big change. What for?

Generally if the operand/register class changes there should be a separate opcode. It avoids needing all this special case checking, and makes folding code work naturally

Anyway, you cannot have two opcodes with the same opcode without introducing a new encoding and a new decoder namespace. This bug will be fixed.

The encoding is the same, and a new decoder namespace shouldn't be an issue

lib/Target/AMDGPU/SIInstrInfo.cpp
2873–2876 ↗(On Diff #216911)

I would expect this to be in RI.opCanUseInlineConstant

Can we have different opcodes with a different source type?

It will be a quite big change. What for?

Generally if the operand/register class changes there should be a separate opcode. It avoids needing all this special case checking, and makes folding code work naturally

Anyway, you cannot have two opcodes with the same opcode without introducing a new encoding and a new decoder namespace. This bug will be fixed.

The encoding is the same, and a new decoder namespace shouldn't be an issue

I still think the change will be too massive. Note, that encoding is still valid and legal.

rampitec marked an inline comment as done.Aug 23 2019, 12:16 PM
rampitec added inline comments.
lib/Target/AMDGPU/SIInstrInfo.cpp
2873–2876 ↗(On Diff #216911)

It does not have a subtarget.

Can these be encoded as a constant literal instead? We would then just need to workaround the encoding rather than disallowing the operand

Can these be encoded as a constant literal instead? We would then just need to workaround the encoding rather than disallowing the operand

It is VOP3, so not in gfx9.

rampitec updated this revision to Diff 216959.Aug 23 2019, 2:32 PM
rampitec marked an inline comment as done.

Moved check into opCanUseInlineConstant().
Captured subtarget in SIRegisterInfo to do this.

arsenm accepted this revision.Aug 23 2019, 2:54 PM

LGTM

This revision is now accepted and ready to land.Aug 23 2019, 2:54 PM
This revision was automatically updated to reflect the committed changes.
Herald added a project: Restricted Project. · View Herald TranscriptAug 23 2019, 3:14 PM
Herald added a subscriber: hiraditya. · View Herald Transcript