bcardosolopes wrote: > if transformations like this should be implemented in cir-simplify
For this specific one I agree with @xlauko, it could have already come out of CIRGen like this without any hurting source fidelity. For anything slightly more cir-simplify should be used. We just went through a similar one with vector (in which the folding to constant vector (from a splat op) can actually increase code size), so we moved it to cir-simplify (and should probably take opt level in consideration in the future). > Though yes, I agree we should have discussion where is the borderline, for > instance UnaryOp::fold is doing more simplification/rewrite than this from my > point of view. Yea, unary and a few others. We already encode the expectation as part of these passes documentation/description, but some are subtle enough that review time is probably the best we can do? https://github.com/llvm/llvm-project/pull/147592 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
