[Bug target/114083] New: Possible word play on conditional/unconditional

[Bug target/114083] New: Possible word play on conditional/unconditional

[roland.illig at gmx dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114083

            Bug ID: 114083
           Summary: Possible word play on conditional/unconditional
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Keywords: documentation
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: roland.illig at gmx dot de
  Target Milestone: ---
            Target: riscv

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.

[Bug target/114083] Possible word play on conditional/unconditional

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114083

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
This is not a play on words though. The flag enables the use of "conditional
moves" always (unconditionally).

[Bug target/114083] Possible word play on conditional/unconditional

[roland.illig at gmx dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114083

--- Comment #2 from Roland Illig <roland.illig at gmx dot de> ---
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.

[Bug target/114083] Possible word play on conditional/unconditional

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114083

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |macro at orcam dot me.uk

--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
CCing Maciej for clarity

[Bug target/114083] Possible word play on conditional/unconditional

[macro at orcam dot me.uk]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114083

--- Comment #4 from Maciej W. Rozycki <macro at orcam dot me.uk> ---
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?

[Bug target/114083] Possible word play on conditional/unconditional

[schwab@linux-m68k.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114083

--- Comment #5 from Andreas Schwab <schwab@linux-m68k.org> ---
Enable conditional-move operations even if unsupported by hardware.

[Bug target/114083] Possible word play on conditional/unconditional

[roland.illig at gmx dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114083

--- Comment #6 from Roland Illig <roland.illig at gmx dot de> ---
(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.

[Bug target/114083] Possible word play on conditional/unconditional

[macro at orcam dot me.uk]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114083

--- Comment #7 from Maciej W. Rozycki <macro at orcam dot me.uk> ---
(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?