diff mbox series

[v4,02/12] bfd/RISC-V: Zve{32,64}f don't need to explicitly imply Zvl{32,64}b

Message ID 93e2c76e-edd5-4293-9d99-04d6bf30b1f4@suse.com
State New
Headers
Series RISC-V: assorted fixes and (hopefully) improvements |

Checks

Context Check Description
linaro-tcwg-bot/tcwg_binutils_build--master-arm success Build passed

Commit Message

Jan Beulich July 24, 2026, 10:02 a.m. UTC 
  The former referencing Zve{32,64}x already ensures the wanted implication.
No need to perform excess processing.
---
v4: New.

Comments

Nelson Chu July 27, 2026, 1:40 a.m. UTC | #1 
Yeah right, thanks.

(Not related to this patch)  To be honest, I’ve been debating whether
this "table implies order" approach is actually a good thing.  While
it significantly reduces the number of table entries, in practice,
every time people add a new rule, they have to be extremely careful to
ensure the order is correct.  Would it be better to define some macro
to represent parts of the rules?

Nelson

On Fri, Jul 24, 2026 at 6:02 PM Jan Beulich <jbeulich@suse.com> wrote:
>
> The former referencing Zve{32,64}x already ensures the wanted implication.
> No need to perform excess processing.
> ---
> v4: New.
>
> --- a/bfd/elfxx-riscv.c
> +++ b/bfd/elfxx-riscv.c
> @@ -1268,8 +1268,8 @@ static const struct riscv_implicit_subse
>    {"zvqwdota16i", "+zve64x", check_implicit_always},
>
>    {"zve64d", "+d,+zve64f", check_implicit_always},
> -  {"zve64f", "+zve32f,+zve64x,+zvl64b", check_implicit_always},
> -  {"zve32f", "+f,+zve32x,+zvl32b", check_implicit_always},
> +  {"zve64f", "+zve32f,+zve64x", check_implicit_always},
> +  {"zve32f", "+f,+zve32x", check_implicit_always},
>    {"zve64x", "+zve32x,+zvl64b", check_implicit_always},
>    {"zve32x", "+zvl32b,+zicsr", check_implicit_always},
>
>
Jan Beulich July 27, 2026, 7:21 a.m. UTC | #2 
On 27.07.2026 03:40, Nelson Chu wrote:
> Yeah right, thanks.
> 
> (Not related to this patch)  To be honest, I’ve been debating whether
> this "table implies order" approach is actually a good thing.  While
> it significantly reduces the number of table entries, in practice,
> every time people add a new rule, they have to be extremely careful to
> ensure the order is correct.  Would it be better to define some macro
> to represent parts of the rules?

I don't think I see how a macro could help here. What I could see as
possibly helping would be to machine-generate this table from a simpler
(purely textual perhaps) representation where order doesn't matter.

Jan
diff mbox series

Patch

--- a/bfd/elfxx-riscv.c
+++ b/bfd/elfxx-riscv.c
@@ -1268,8 +1268,8 @@  static const struct riscv_implicit_subse
   {"zvqwdota16i", "+zve64x", check_implicit_always},
 
   {"zve64d", "+d,+zve64f", check_implicit_always},
-  {"zve64f", "+zve32f,+zve64x,+zvl64b", check_implicit_always},
-  {"zve32f", "+f,+zve32x,+zvl32b", check_implicit_always},
+  {"zve64f", "+zve32f,+zve64x", check_implicit_always},
+  {"zve32f", "+f,+zve32x", check_implicit_always},
   {"zve64x", "+zve32x,+zvl64b", check_implicit_always},
   {"zve32x", "+zvl32b,+zicsr", check_implicit_always},