AMDGPUCodeGenPrepare should stop promoting uniform i16 values

[arsenm]

With DAG divergence and RegBankSelect, theoretically, codegen should now have enough information to handle the promotion of uniform 16-bit ops directly. This was originally done as a workaround for having no uniformity info after the IR.

AMDGPUCodeGenPrepare awkwardly uses forward iteration, which just so happens to work around a defect in uniformity info where newly created values are assumed uniform. I currently have a problem that requires iterating in reverse like a normal combiner, and this is blocking the reversal

[llvmbot]

@llvm/issue-subscribers-backend-amdgpu

[kzhuravl]

Need to re-assign to Jun.

[kzhuravl]

Jun is working on other issues. Pierre, can you take a look at this one?

[Pierre-vh]

@arsenm Is it just a matter of removing all i16 promotion logic from AMDGPUCodeGenPrepare (as-if Widen16BitOps was always false) or are there other things to do as well?

Is this about moving all of the i16 promotion logic to DAG/GISel, or is that already implemented?

[arsenm]

@arsenm Is it just a matter of removing all i16 promotion logic from AMDGPUCodeGenPrepare (as-if Widen16BitOps was always false) or are there other things to do as well?

Is this about moving all of the i16 promotion logic to DAG/GISel, or is that already implemented?

Yes, I assume other work needs to be done to avoid regressions. I don't think any of the relevant work has been implemented in the codegen side, it's just more tractable with DAG divergence info

[Pierre-vh]

@arsenm I got started on this, but I'm having some trouble.

I initially started implementing this as a new LowerOperation case, by adding a Custom legalization to all of the operations I wanted to look at. This more or less works but I run into issues because sometimes we don't want to promote (when the value is uniform), but the operation is still marked as illegal and:

• if I return SDValue(), the legalizer will try to expand/fallback to something else, making things worse.
• if I return the original node, an assertion failure happens for some operations as "potential combine loop" is detected, IIRC.

I then tried making it a combine, but it's even worse, it gets into all sorts of combine loops because the combiner really hates trunc (op ...) when op can be narrowed.

So I assume the Custom legalization path is the correct tone, but I can't figure out how to tell the legalizer that we intentionally didn't lower an operation?

[arsenm]

Presumably you need to make isNarrowingProfitable aware of the specific node (such that we can check the divergence bit), and then do something to visitTRUNCATE to prevent it from narrowing