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

2024-03-06 Thread macro at orcam dot me.uk via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114083

--- Comment #7 from Maciej W. Rozycki  ---
(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?

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

2024-03-04 Thread roland.illig at gmx dot de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114083

--- Comment #6 from Roland Illig  ---
(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

2024-02-24 Thread schwab--- via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114083

--- Comment #5 from Andreas Schwab  ---
Enable conditional-move operations even if unsupported by hardware.

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

2024-02-23 Thread macro at orcam dot me.uk via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114083

--- Comment #4 from Maciej W. Rozycki  ---
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

2024-02-23 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114083

Jonathan Wakely  changed:

   What|Removed |Added

 CC||macro at orcam dot me.uk

--- Comment #3 from Jonathan Wakely  ---
CCing Maciej for clarity

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

2024-02-23 Thread roland.illig at gmx dot de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114083

--- Comment #2 from Roland Illig  ---
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

2024-02-23 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114083

--- Comment #1 from Andrew Pinski  ---
This is not a play on words though. The flag enables the use of "conditional
moves" always (unconditionally).