Andrew Stubbs <a...@codesourcery.com> writes: > On 27/09/18 08:16, Richard Sandiford wrote: >> On keeping the complexity down: >> >> if (side_effects_p (x)) >> return NULL_RTX; >> >> makes this quadratic for chains of unary operations. Is it really >> needed? The code after it simply recurses on operands and doesn't >> discard anything itself, so it looks like the VEC_MERGE call to >> side_effects_p would be enough. > > The two calls do not check the same thing. The other one checks the > other operand of a vec_merge, and this checks the current operand. > > I suppose it's safe to discard a VEC_MERGE when the chosen operand > contains side effects, but I'm not so sure when the VEC_MERGE itself is > an operand to an operator with side effects. I'm having a hard time > inventing a scenario in which a PRE_INC could contain a VEC_MERGE, but > maybe a volatile MEM or ASM_OPERANDS could do?
But we wouldn't recurse for PRE_INC, MEM or ASM_OPERANDS, since they have the wrong rtx class. AFAICT no current unary, binary or ternary operator has that level of side-effect (and that's a good thing). We also don't guarantee to preserve FP exceptions as side-effects. > Conversely, I don't see that side-effects deep down in an expression > should stop us transforming it as a high level. > > Is there an equivalent to side_effects_p that doesn't recurse? Should > there be? Not aware of an existing function, and it might be useful to have one at some point. Just not sure we need it for this. Richard
