search for: canreplaceoperandwithvariable

...7 for a recent example fix). From the codegen side, we do things like folding invalid intrinsic calls to undef during custom lowering, which is more boilerplate which shouldn’t be necessary. It’s also necessary in a few some passes to know it’s illegal to replace an argument with a constant. llvm::canReplaceOperandWithVariable currently has to conservatively assume any intrinsic arguments can’t be touched. I have 2 versions of partial implementations of this. 1. Uses a new intrinsic query table to return a bitmask of which operands need to be constant 2. Introduces a new parameter attribute My current preference...

Probably the issue is solvable in some Codegen prepare pass. That said I still believe some kind of control on if we would like to implement this or not could be useful. Just a question. Why implementing it in SimplifyCFG and not as a separate pass like JumpThreading or something like that? The transformation itself doesn’t seem to fit much in SimplifyCFG. > On 2 Sep 2016, at 13:35, Michael

...select between the address. >>> This breaks our selection of this types of loads. > > Are you referring to a downstream intrinsic, an upstream intrinsic or are you somehow adding strange restrictions yourself on what a load instruction can and can’t do? > > There’s a function canReplaceOperandWithVariable() that this optimisation uses to decide if it’s possible to do this. We use this to avoid making things that must be constant (like your example) variable. Perhaps this is doing something wrong? If you’re adding arbitrary restrictions on what loads can do though that’s never going to go well - I’m...