This is an archive of the discontinued LLVM Phabricator instance.

[GlobalISel] Refactor CSEMIRBuilder's handling of unary op constant folding. NFC.
Needs ReviewPublic

Authored by aemerson on Oct 13 2021, 11:17 PM.

Details

Summary

This allows us to handle more unary ops in future in a simpler way, and G_CTLZ is the first opcode to get this treatment.

Diff Detail

Event Timeline

aemerson created this revision.Oct 13 2021, 11:17 PM
aemerson requested review of this revision.Oct 13 2021, 11:17 PM
aemerson added inline comments.Oct 13 2021, 11:19 PM
llvm/lib/CodeGen/GlobalISel/CSEMIRBuilder.cpp
226

The plan is to add support for constant folding more unary opcodes (e.g. G_ABS) by just adding more cases here, and then implementing the folding in ConstantFoldUnaryOp()

foad added a comment.Oct 15 2021, 2:24 AM

No particular objection from me, though it would be more consistent if ConstantFoldUnaryOp built the G_CONSTANT, just like ConstantFoldVectorUnaryOp builds the G_BUILD_VECTOR.

That then raises the question of how you would call these functions from CombinerHelper match* functions, which don't want to build the IR until you get to the corresponding apply* function.

That then also raises the question of whether we really want to be doing constant folding both in the builder and in combiners.

No particular objection from me, though it would be more consistent if ConstantFoldUnaryOp built the G_CONSTANT, just like ConstantFoldVectorUnaryOp builds the G_BUILD_VECTOR.

That then raises the question of how you would call these functions from CombinerHelper match* functions, which don't want to build the IR until you get to the corresponding apply* function.

That then also raises the question of whether we really want to be doing constant folding both in the builder and in combiners.

I think the answer is yes, but for different reasons. I think constant folding in the builder only makes sense for handful of artifact-like operations, but general constant folding is always going to be needed in the combiners as other operations fold to constants

No particular objection from me, though it would be more consistent if ConstantFoldUnaryOp built the G_CONSTANT, just like ConstantFoldVectorUnaryOp builds the G_BUILD_VECTOR.

That then raises the question of how you would call these functions from CombinerHelper match* functions, which don't want to build the IR until you get to the corresponding apply* function.

That then also raises the question of whether we really want to be doing constant folding both in the builder and in combiners.

I think the answer is yes, but for different reasons. I think constant folding in the builder only makes sense for handful of artifact-like operations, but general constant folding is always going to be needed in the combiners as other operations fold to constants

I agree, but I think there's also the case where the MIRBuilder may be being used at a point in the pipeline where another combine phase isn't coming to save the day. There could be value in having the builder be proactive about not leaving behind constant-foldable instructions.

arsenm added inline comments.Nov 16 2022, 3:09 PM
llvm/include/llvm/CodeGen/GlobalISel/Utils.h
283

I'm not the biggest fan of Optional on pointers. It's not really any safer than the raw pointer for C++ and more syntactically awkward

Herald added a project: Restricted Project. · View Herald TranscriptNov 16 2022, 3:09 PM