[PATCH] D78887: [VE] Support floating point immediate values

[Simon Moll via Phabricator via llvm-commits]

simoll accepted this revision.
simoll added a subscriber: arsenm.
simoll added a comment.
This revision is now accepted and ready to land.

LGTM, then. We should followup on the denormal fp constant issue (getting @arsenm in the loop who has been working on proper fp support).



================
Comment at: llvm/test/CodeGen/VE/fp_mul.ll:97
+; CHECK-NEXT:    or %s11, 0, %s9
+  %r = fmul float %a, 1.175494210692441075487029444849287348827052428745893333857174530571588870475618904265502351336181163787841796875E-38
+  ret float %r
----------------
kaz7 wrote:
> simoll wrote:
> > kaz7 wrote:
> > > simoll wrote:
> > > > I guess this is one of those cases where it makes sense to use a fp hex constant: it is shorter and the expected output relates to the bitencoding anyway.
> > > I wish I could.  Recently, llvm is modified to not use hex values in llvm-ir.  After that, llc doesn't accept hex values when I tried to use hex values.  Please let me know if you know how to write it in the current version.  Thanks.
> > The IR in line 61 uses a hex fp constant. I'd expect this to work here too.
> Yeah.  That causes these errors.  I tried them and I failed previously.
> 
> If I try 0x007FFFFF:
> ```
> /usr/uhome/aurora/fccg/marukawa/llvm-dev/build-debug-upstream/bin/llc: error: /usr/uhome/aurora/fccg/marukawa/llvm-dev/build-debug-upstream/bin/llc: <stdin>:97:23: error: floating point constant invalid for type
>   %r = fmul float %a, 0x007FFFFF
> ```
> If I try 0x007FFFFFFFFFFFFF:
> ```
> /usr/uhome/aurora/fccg/marukawa/llvm-dev/build-debug-upstream/bin/llc: error: /usr/uhome/aurora/fccg/marukawa/llvm-dev/build-debug-upstream/bin/llc: <stdin>:97:23: error: floating point constant invalid for type
>   %r = fmul float %a, 0x007FFFFFFFFFFFFF
> ```
Apparently, LLVM does not like denormal hex fp constants. I suppose that should be considered a bug since it is still a valid fp specification.
We should not stall this patch until that is fixed but look up the rationale for not accepting denormals and/or raise the issue on llvm-dev.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D78887/new/

https://reviews.llvm.org/D78887