tgross35 wrote: I think something like the following precedence would make sense for all targets:
1. Direct asm: Lower to assembly if hardware support is available 2. Indirect mixed: libcall f16->f32 then asm the second conversion (f32->f64 or f32->f128) if hardware is available. The advantage is only linking one libcall (extendhfsf) 3. Direct libcall: If f32->f64 or f32->f128 are not hardware supported, use extendhfsf, extendhfdf, or extendhftf to lower f16->f32, f16->f64, a f16->f128 4. Indirect libcalls: this is LLVM's current behavior without hard float, i.e. libcall f16->f32 and then libcall again for f32->f64 or f32->f128 Option 2 is probably best here. Does s390x have `+soft-float` or any features that toggle the availability of float conversion ops? In these cases I think option 3 is preferable to option 4. (Although since the other targets seem to fall back to option 4, maybe this something that could be fixed globally?) https://github.com/llvm/llvm-project/pull/109164 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
