Home Original page

[PATCH v1] RISC-V: Let fcvt.* recognize rounding mode != 0

Hau Hsu hau.hsu@sifive.com
Wed Oct 16 02:06:25 GMT 2024 
More context:
Previously LLVM generated instructions to use DYN rounding mode for fcvt.s.bf16.
We got errors when using gas to assemble the code generated by LLVM.
The LLVM codegen is mysterious and Craig had a PR to fix it:
https://github.com/llvm/llvm-project/pull/106948/commits/90aa61e0dbbf2442dfd49bb645c31f7debf0f4e0 
But still he reported this issue and I had this patch.

Hau






> On Oct 16, 2024, at 4:24 AM, Andrew Waterman <andrew@sifive.com> wrote:
> 
> On Tue, Oct 15, 2024 at 8:17 AM Nelson Chu <nelson@rivosinc.com <mailto:nelson@rivosinc.com>> wrote:
>> 
>> 
>> 
>> On Tue, Oct 15, 2024 at 8:42 PM Jan Beulich <jbeulich@suse.com> wrote:
>>> 
>>> On 15.10.2024 11:30, Hau Hsu wrote:
>>>> For those floating point convert instructions that convert from lower
>>>> precisions to higher precisions, although the rounding mode has no
>>>> effects, the spec doesn’t forbid them to be values other than zero.
>>> 
>>> Yet what's the point of permitting the use of misleading operands? In the
>>> commit you refer to below I specifically said that the non-standard 3-
>>> operand forms are left merely to avoid breaking existing code. At some
>>> point I think use of them should actually be warned about, to allow their
>>> removal at a yet later point.
>> 
>> 
>> Hey Jan,
>> 
>> Personally, I agree and support that permitting the use of misleading operands looks weird, even though the random test generator people are always not happy about it.  Anway, I found this old discussion, https://github.com/riscv/riscv-isa-manual/issues/603.  So...
>> 
>> Hey Andrew,
>> 
>> Seems that this patch is trying to do the things that the above link mentioned - allow the unaffected rm field of fp widening conversion instructions.  Is this still valid now?  If that is so, then not only instructions in this patch need to be fixed.
> 
> Using a nonzero rm field is definitely legal at the ISA level.
> 
> I don't have a strong opinion on this one.  It's benign to allow
> these, but they're only useful for DV, not application software.  If
> that is (or isn't) deemed to be a good enough reason, fine by me, but
> we should stay philosophically consistent going forward.
> 
>> 
>> Thanks
>> Nelson

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://sourceware.org/pipermail/binutils/attachments/20241016/f39e2203/attachment.htm>
More information about the Binutils mailing list