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
- Repository
- rG LLVM Github Monorepo
Unit Tests
Time | Test | |
---|---|---|
1,420 ms | x64 debian > libomp.tasking::kmp_taskwait_depend_all.c |
Event Timeline
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() |
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.
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 |
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