> This may ultimately be too simplistic. There are targets where some > constants are OK, but others may not be. By checking the predicate > like this I think you can cause over-aggressive if-conversion if the > target allows a range of integers in the expander's operand predicate, > but allows a narrower range in the actual define_insn (presumably the > expander loads them into a pseudo or somesuch in that case). > > We know that over-aggressive if-conversion into conditional moves hurts > some targets. > > Ideally you'd create the actual insn with the constants you want to use > and see if that's recognized as well as compute its cost. Is that just > too painful at this point for some reason?
Conditional moves in noce_convert_multiple_sets are processed via noce_emit_cmove which itself performs quite some preprocessing and calls optab's emit_conditional_move in the end, so the insn will already be emitted before being able to decide whether to decline it due to costs. In addition, every noce_emit_cmove will emit the condition check again as well as possible temporaries. Comparing the costs of the whole sequence will therefore still prove difficult as all the additionally generated insns will not get removed until reload and make a fair comparison nigh impossible. I was reluctant to factor out all the preprocessing stuff, separate it from the condition check and actual emitting part but that's properly the "right way" to do it, including emitting the condition only once in the beginning. However, for now, I could imagine changing only the conversion_profitable_p hook in our backend to only count the cmovs and ignore everything else in the sequence. This would be somewhat hacky though and still wouldn't allow constants :) Regards Robin
