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

[Craig Topper]

Here's an older related LLVM patch from Alex Bradbury
https://github.com/llvm/llvm-project/pull/67555 for fcvt.d.s and other
instructions.

On Tue, Oct 15, 2024 at 7:06 PM Hau Hsu <hau.hsu@sifive.com> wrote:

> 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> 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/20241015/4d6c5d69/attachment.htm>