[REVIEW ONLY 4/4] RISC-V: Tentative ".bfloat16" assembly support

[Nelson Chu]

Since risc-v assembler supported bf16 instructions recently, just make sure
that - should we still need this patch to support the .bfloat16 directive?
Seems arm32 still support bfloat instructions but without supporting the
.bfloat16 directive.

Thanks
Nelson

On Thu, Aug 3, 2023 at 4:26 PM Jan Beulich via Binutils <
binutils@sourceware.org> wrote:

> On 03.08.2023 10:21, Tsukasa OI wrote:
> > On 2023/08/03 17:00, Jan Beulich via Binutils wrote:
> >> On 03.08.2023 09:51, Tsukasa OI wrote:
> >>> On 2023/08/03 16:17, Tsukasa OI via Binutils wrote:
> >>>>
> >>>>
> >>>> On 2023/08/03 15:47, Jan Beulich wrote:
> >>>>> On 03.08.2023 02:04, Tsukasa OI via Binutils wrote:> ---
> a/gas/config/tc-riscv.c
> >>>>>> +++ b/gas/config/tc-riscv.c
> >>>>>> @@ -437,7 +437,7 @@ const char EXP_CHARS[] = "eE";
> >>>>>>
> >>>>>>  /* Chars that mean this number is a floating point constant.
> >>>>>>     As in 0f12.456 or 0d1.2345e12.  */
> >>>>>> -const char FLT_CHARS[] = "rRsSfFdDxXpPhH";
> >>>>>> +const char FLT_CHARS[] = "rRsSfFdDxXpPhHb";
> >>>>>
> >>>>> I realize Arm64 also has it this way (x86 doesn't), but are you sure
> >>>>> about only adding 'b' and not also 'B'? Aiui this introduces a
> needless
> >>>>> special case of case sensitivity.
> >>>>
> >>>> I'm not sure (the only reason I did so is because what I saw is
> AArch64
> >>>> code).  So, I'll investigate whether introducing additional character
> >>>> will benefit (I think there's not so many cases but there might be at
> >>>> least one).
> >>>
> >>> I checked the code and actually, no code is affected by lacking 'B'.  I
> >>> first thought something like 0B:1234 (raw hexadecimal representation as
> >>> float) is affected but in a floating number literal, any 0[a-zA-Z]:1234
> >>> turns to a 16-bit word 0x1234, reinterpreted as a floating point number
> >>> (and the second character is just ignored and the length is checked
> >>> against another parameter).
> >>
> >> I'm actually questioning that overly lax check; IOW I wonder whether it
> >> shouldn't consult FLT_CHARS[].
> >
> > Hmm, I'm tempted to say "don't ask me".  I mean, that overly lax check
> > is in the portable portion of GAS and not RISC-V-specific.
>
> Of course. My remark went towards: Wouldn't it be better if targets weren't
> dependent on that overlay lax check? (Interestingly Arm32, despite
> supporting bfloat16, looks to have neither b nor B in it FLT_CHARS[], and
> is - for now - still getting away with that.)
>
> Jan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://sourceware.org/pipermail/binutils/attachments/20240614/9664efde/attachment-0001.htm>