This is an archive of the discontinued LLVM Phabricator instance.

[SPIR-V] Begin removing explicit setRegClass calls
Needs ReviewPublic

Authored by zuban32 on Jun 15 2023, 10:01 PM.

Details

Summary

As a part of a general cleanup of SPIRV's instruction selection
we want to remove explicit setRegClass calls which happen in some
SPIRV-specific pre-selection lowering passes. As these calls only
concern finally emitted SPIRV instructions and not MIR ones we can
easily constrain them.

This change removes the calls everywhere except for the builtins-
related code, that will require more effort to refactor the overall
bultins emission code.

Diff Detail

Event Timeline

zuban32 created this revision.Jun 15 2023, 10:01 PM
Herald added a project: Restricted Project. · View Herald TranscriptJun 15 2023, 10:01 PM
zuban32 requested review of this revision.Jun 15 2023, 10:01 PM
Herald added a project: Restricted Project. · View Herald Transcript

Could you please get rid of these calls to constrainSelectedInstRegOperands?

llvm/lib/Target/SPIRV/SPIRVCallLowering.cpp
321–322

constrainSelectedInstRegOperands should be called from InstructionSelector only. We also have it in methods of SPIRVGlobalRegistry but these methods are called from InstructionSelector.

334

The same issue with constrainSelectedInstRegOperands.

llvm/lib/Target/SPIRV/SPIRVGlobalRegistry.cpp
737

It can be the issue with constrainSelectedInstRegOperands if it's called outside InstructionSelector.

986

It can be the issue with constrainSelectedInstRegOperands if it's called outside InstructionSelector.

llvm/lib/Target/SPIRV/SPIRVPreLegalizer.cpp
217

The same issue with constrainSelectedInstRegOperands.

344

The same issue with constrainSelectedInstRegOperands.

There are some new regressions after this individual patch, we are hitting an assert in SPIRVInstructionSelector for example in integer_ops / long_logic. Full testing results: https://spirv-testing.khronos.org/job/142/

test_integer_ops: /home/bot/Workspace/llvm-monorepo/llvm/lib/Target/SPIRV/SPIRVInstructionSelector.cpp:228: virtual bool {anonymous}::SPIRVInstructionSelector::select(llvm::MachineInstr&): Assertion `Res || Def->getOpcode() == TargetOpcode::G_CONSTANT' failed.
zuban32 added inline comments.
llvm/lib/Target/SPIRV/SPIRVCallLowering.cpp
321–322

This is the whole point of the patch - these instructions are built before selection, but we need to have them constrained in order to support selection of instruction that depend on them (like G_ADD adding two OpFunctionParameter's). Using setRegClass explicitly is wrong since these classes are already described by the instruction description in tablegen. I remember @arsenm pointed out the problem a while ago.

@iliya-diyachkov do you see any particular issue with calling these funcs from here? I see there're a couple of non-selector uses in AMDGPU RegBankSelect and MIPS legalizer. Anyway, I don't see any viable alternative.

llvm/lib/Target/SPIRV/SPIRVCallLowering.cpp
321–322

@zuban32 no particular problem, except that this is the wrong place to call this interface. As you write, you are going to continue removing setRegClass in builtins-related code, so you will need to insert much more calls to constrainSelectedInstRegOperands outside of InstructionSelector.

Am I right that D153101 patch (with a small fix) can be applied without this one? In my sandbox, it passes all lit tests. If so, it would be nice to test it on OpenCL CTS.

I understand that using setRegClass is logically excessive (and may look unsightly) since we have the info in the instruction description, however (as I see it) other targets also use setRegClass in this way.

On other hand, as we discussed earlier, we are going to exclude "global" instructions from the function level. Many instructions (which require setRegClass) are "global", so they will go away from IR with no need to call constrainSelectedInstRegOperands outside of InstructionSelector. Generation of others (mainly in SPIRVBuiltins.cpp) can probably be moved to InstructionSelector. After this, we will have a few instructions that require setting of reg class before InstructionSelector (like in AMDGPU/MIPS), which is acceptable.

So, I propose either to postpone this patch and commit other two patches (and continue the plan described before), or to mark all inserted constrainSelectedInstRegOperands calls with "FIXME" comment with the obligation to remove them when we find a better solution, and try not to spread such use of constrainSelectedInstRegOperands in the next patches.

zuban32 added inline comments.Aug 16 2023, 9:40 PM
llvm/lib/Target/SPIRV/SPIRVCallLowering.cpp
321–322

@zuban32 no particular problem, except that this is the wrong place to call this interface

Why particularly? If you are aware of the exact issue this can cause pls share that

. As you write, you are going to continue removing setRegClass in builtins-related code, so you will need to insert much more calls to constrainSelectedInstRegOperands outside of InstructionSelector.

That's right, and that was supposed to be the aim of my subsequent patches.

Am I right that D153101 patch (with a small fix) can be applied without this one? In my sandbox, it passes all lit tests. If so, it would be nice to test it on OpenCL CTS.

I understand that using setRegClass is logically excessive (and may look unsightly) since we have the info in the instruction description, however (as I see it) other targets also use setRegClass in this way.

From what I see these targets are doing that mainly during or after selection.

On other hand, as we discussed earlier, we are going to exclude "global" instructions from the function level. Many instructions (which require setRegClass) are "global", so they will go away from IR with no need to call constrainSelectedInstRegOperands outside of InstructionSelector. Generation of others (mainly in SPIRVBuiltins.cpp) can probably be moved to InstructionSelector. After this, we will have a few instructions that require setting of reg class before InstructionSelector (like in AMDGPU/MIPS), which is acceptable.

I think the problem that I was trying to solve is to avoid this 'manual' regclass setting (which BTW sometimes led to some verifier errors, I don't recall the exact usecase, I'll find it and post here) by leaving it all to the automated utilities based on the instruction description that already exists.

So, I propose either to postpone this patch and commit other two patches (and continue the plan described before), or to mark all inserted constrainSelectedInstRegOperands calls with "FIXME" comment with the obligation to remove them when we find a better solution, and try not to spread such use of constrainSelectedInstRegOperands in the next patches.