riscv.opts says: > mmovcc > Target Var(TARGET_MOVCC) > Enable conditional moves unconditionally. Is the conditional/unconditional a play of words? As the German translator, I find it more confusing than helpful. Or is there a deeper meaning? In that case, the option description should be longer.
This is not a play on words though. The flag enables the use of "conditional moves" always (unconditionally).
I don't understand why the word 'unconditionally' is necessary or useful here. Isn't the option -mmovcc by itself already a condition? That would make the word 'unconditionally' wrong.
CCing Maciej for clarity
The flag enables the use of the conditional-move operations even with hardware that has no support for such operations, hence unconditionally. Such operations, where unavailable, are then synthesized as sequences of instructions from other operations, avoiding the use of branches where they'd turn out more costly according to the `-mbranch-cost=' setting (either specified or inferred from the `-mtune=' setting in effect). Normally the compiler only enables conditional-move operations where directly provided by hardware, according to the `-march=' or `-mcpu=' options used for compilation (either specified or defaulted). The help line is too short to provide a more elaborate explanation and merely serves as a quick reminder saving one from reaching for the manual. I hope this is good enough for this purpose, but if someone has a better proposal, then please feel free to submit a patch. Or would: Enable conditional-move operations unconditionally. be preferable? Last but not least, did my explanation help with the translation?
Enable conditional-move operations even if unsupported by hardware.
(In reply to Maciej W. Rozycki from comment #4) > The flag enables the use of the conditional-move operations even with > hardware that has no support for such operations, hence unconditionally. Thank you for your explanation, that made the intention much clearer to me. There's a problem with the wording though. On a platform that doesn't support conditional-move operations, it's not possible to _use_ conditional-move operations. Period. It's only possible to _emulate_ the behavior of these operations. I'm not sure how consistently the words 'operation' and 'instruction' are used in the GCC code base and documentation, but I mixed them up in my mind when I tried to translate this option. > if someone has > a better proposal, then please feel free to submit a patch. Or would: > > Enable conditional-move operations unconditionally. > > be preferable? No. Above, you wrote that the branchless instructions would be selected _if_ they are cheaper than the equivalent branch instructions. This is a condition, thus the word 'unconditionally' doesn't fit. What about this? > Prefer branchless move instructions where cheaper.
(In reply to Roland Illig from comment #6) > There's a problem with the wording though. On a platform that doesn't > support conditional-move operations, it's not possible to _use_ > conditional-move operations. Period. It's only possible to _emulate_ the > behavior of these operations. There's just too much implementer's speak in the option description here. Sorry about this. What the option internally enables it is a set of named RTL machine description patterns that implement the respective conditional-move operations. So in terms of RTL the operations are indeed available unconditionally. But I guess the compiler's internal representation is less of an interest from the user's point of view. What do you think of Andreas's suggestion for the English wording?