This is an archive of the discontinued LLVM Phabricator instance.

AMDGPU: Simplify VOP2 operand legalization
AbandonedPublic

Authored by arsenm on Sep 22 2015, 7:32 PM.

Details

Reviewers
tstellarAMD
Summary

Checking the legality of src0 is pointless since
it can accept any type of operand.

Also skips the more complex checks for checking
literal operands and constant bus restrictions.
These should not be a concern when performing
legalization.

This gets called quite a few times and the
attempts at commuting are a significant fraction
of the time spent in SIFixSGPRCopies, so it's
somewhat worthwhile to optimize.

Diff Detail

Event Timeline

arsenm updated this revision to Diff 35455.Sep 22 2015, 7:32 PM
arsenm retitled this revision from to AMDGPU: Simplify VOP2 operand legalization.
arsenm updated this object.
arsenm added a reviewer: tstellarAMD.
arsenm added a subscriber: llvm-commits.
lib/Target/AMDGPU/SIInstrInfo.cpp
802–805

This isn't true for instructions with implicit defs/uses of VCC.

I prefer the explicit operand checking for legalization rather than make assumptions based on the instruction type, because there are usually one or two corner cases for each instruction type.

arsenm added inline comments.Oct 6 2015, 1:02 PM
lib/Target/AMDGPU/SIInstrInfo.cpp
802–805

This isn't a concern here because commuteInstruction shouldn't ever see an illegal operand combination / constant bus restriction violation. Part of this set of changes it separating commuting for the common code's purposes (e.g. MachineCSE) and operand legalization. The only times constant bus violations are OK is coming out of isel and as an intermediate step during moveToVALU. This function shouldn't be used for legalization purposes. The constant bus restrictions should only be handled in legalizeOperands, although I need to double check if the VCC check is handled there already. For the implicit VCC cases, we should probably use an operand type that only includes VGPRs + inline immediate for src0/src1.

This patch didn't apply cleanly, so I'm not sure if I applied it wrong, but I am getting an assertion failure with this test case: http://people.freedesktop.org/~tstellar/fail.ll

arsenm abandoned this revision.Oct 21 2015, 3:17 PM

This patch didn't apply cleanly, so I'm not sure if I applied it wrong, but I am getting an assertion failure with this test case: http://people.freedesktop.org/~tstellar/fail.ll

I don't see the assert when I rebase it. However I do see a lot of verifier errors which are fixed by the next patch, so I split them wrong. I'll just squash this into the other one