[llvm-dev] Potential bug in SelectionDAGLegalize::ConvertNodeToLibcall()?

[Alex Bradbury via llvm-dev]

On Wed, 2 Jan 2019 at 15:54, Justin Hibbits via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>
> Hi,
>
> I have a custom lowering operation on ISD::BITCAST for the PowerPC/SPE
> target, to convert 'f64 bitcast (i64 build_pair i32, i32)' into a 'f64
> BUILD_SPE64 i32, i32' node, which can be seen at
> https://reviews.llvm.org/D54583. However, when building compiler-rt's
> lib/builtins/divdc3.c an assertion is triggered that BUILD_PAIR is not
> legal on line 24.  There should be no bitcast(buildpair) anywhere in
> the generation, as it should all be lowered.  However, this is not the
> case when lowering to a libcall it seems.  The relevant debug output,
> is here:
>
> Creating new node: t118: i64 = build_pair t117,t116, /home/chmeee/freebsd/contrib/compiler-rt/lib/builtins/divdc3.c:24:22
> Creating new node: t119: f64 = bitcast t118, /home/chmeee/freebsd/contrib/compiler-rt/lib/builtins/divdc3.c:24:22
> Created libcall: t119: f64 = bitcast t118, /home/chmeee/freebsd/contrib/compiler-rt/lib/builtins/divdc3.c:24:22
> Successfully converted node to libcall
>  ... replacing: t38: f64 = fmaxnum t36, t37, /home/chmeee/freebsd/contrib/compiler-rt/lib/builtins/divdc3.c:24:22
>      with:      t119: f64 = bitcast t118, /home/chmeee/freebsd/contrib/compiler-rt/lib/builtins/divdc3.c:24:22
>
> Is this a real bug, or am I missing something in my patch?  After
> spending quite a while on it I'm at a loss.

Hi Justin,

I don't think this is a bug in ConvertNodeToLibCall - rather, it's
just a case where you can be tripped up by the very late lowering of
intrinsics calls. This takes place post-legalisation. The issue isn't
the build_pair, it's the fact that you're constructing an i64 prior to
bitcasting to f64, and i64 is not legal on your target. Because these
bitcasts can be introduced so late, a custom bitcast lowering strategy
won't work.

It might be helpful to look at how I handle passing f64 on RISC-V. See
BuildPairF32 and SplitF64 in lib/Target/RISCV. I can't guarantee this
is the _best_ way of handling this sort of problem, but I did explore
quite a lot of options including a similar approach to the custom
bitcast lowering strategy you use here. I'm following this thread
closely to see if there are suggestions for better ways of handling
this issue. The custom inserter shouldn't be necessary in your case -
for RV32FD we don't have an instruction to directly transfer from a
64-bit FPR to the 32-bit GPRs.

Best,

Alex