rogfer01 added a comment.

I'm curious about how we handle `_Float16` here.

My understanding from the psabi 
<https://github.com/riscv-non-isa/riscv-elf-psabi-doc/blob/master/riscv-cc.adoc#hardware-floating-point-calling-convention>
 and the Zfh draft 
<https://drive.google.com/file/d/1GJb230aA2HKkRJ2jqw5bRL0q3FOPQMrN/view>, don't 
we want under `Zfh` + `ilp32f` to pass the float16 directly in a FP register?

So for a case like this

  typedef _Float16 FP;
  typedef struct A { FP a; FP b; } A;
  
  void foo(A);
  
  void bar()
  {
      A a = {1.0, 2.0};
      foo(a);
  }

I'd expect  `Zfh` +  ilp32` to pass an `i32` (which we already do)

  define dso_local void @bar() local_unnamed_addr #0 {
    tail call void @foo(i32 1073757184) #2
    ret void
  }

and `Zfh` + `ilp32f` (and I understand `ilp32d` too) do

  define dso_local void @bar() local_unnamed_addr #0 {
    tail call void @foo(half 1.0e+0.0, half 2.0e+0.0)
    ret void
  }

Perhaps it was already decided against using FP regs for `_Float16`?

I think a similar consideration can be done for `rv64` + `Zfh` and `lp64` / 
`lp64f` / `lp64d`, the last two using FP registers.

If this is the case, then I understand a parameter like

  typedef struct A { _Float16 a; float b; } A;

would also be passed as two FP registers in `ilp32f`, `ilp32d`, `lp64f` and 
`lp64d`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112398

_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
  • [PATCH] D112398: [RISC... Roger Ferrer Ibanez via Phabricator via cfe-commits

Reply via email to