Hi, > On optimizing for speed, default_noce_conversion_profitable_p() allows > plenty of headroom, so this patch has little impact. > > Also, if the target-specific cost estimate is accurate or allows for > margins, the impact should be similarly small. I believe this part of ifcvt does/did not use the costing on purpose. It will generally convert more sequences than other paths that compare before and after costs since we just count the number of converted insns comparing them against the "branch costs". Similar to rtx costs they are kind of relative to a single insn but AFAIK it's not used consistently everywhere. All the major platforms have low branch costs nowadays (0 or 1?) thus we won't emit too many conditional moves here.
In general I agree that we should compare costs everywhere and not just count (the costing should include the branch costs as well) but this would be a major overhaul. For your case (assuming xtensa), could you not tune xtensa_branch_cost? It is currently 3 allowing up to 4 conditional moves to be generated. optimize_function_for_speed_p is already being passed to the hook so you could make use of that and decrease branch costs when optimizing for size only. Regards Robin
