search for: gk9fel

...lvm/lib/Transforms/InstCombine/InstCombineMulDivRem.cpp#L268 We could say that the canonicalization should be reversed, but that probably uncovers more missing optimizations. The code size concern is legitimate. For example on x86, gcc asm is 2 bytes smaller on this example: https://godbolt.org/z/GK9FEL To improve this, we could add a generic transform to DAGCombiner to invert the transform that was done in IR. That transform would only be enabled with a TargetLowering hook that allows targets to decide if the constants or other factors (optimizing for size) make it worthwhile to reorder the ops....

...DivRem.cpp#L268 >> >> We could say that the canonicalization should be reversed, but that probably uncovers more missing optimizations. >> >> The code size concern is legitimate. For example on x86, gcc asm is 2 bytes smaller on this example: >> https://godbolt.org/z/GK9FEL >> >> To improve this, we could add a generic transform to DAGCombiner to invert the transform that was done in IR. That transform would only be enabled with a TargetLowering hook that allows targets to decide if the constants or other factors (optimizing for size) make it worthwhile t...

Hi, James, Thanks for your reply. I do not think it is always true, that "mul then add" is faster than "add then mul". For example, A small immediate can be directly encoded in the instruction, but it becomes a larger one after a multiplication, which has to be loaded from the constant pool (extra memory access). So I wonder, is it possile to prevent it, via changes