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

Nemanja Ivanovic via llvm-dev llvm-dev at lists.llvm.org
Wed Jan 2 08:39:59 PST 2019

It sounds like the legalizer is lowering `fmaxnum` to a libcall because it
is not a legal node for `f64` and in doing so, it is producing the
`build_pair` to reassemble the results of the libcall. And presumably, it
is assuming that the new nodes do not need legalization or something along
those lines.

Justin, it would probably be good if you could provide the DAG before and
after legalization both with and without your patch. Then we can see how it
was handled before your patch and how it is handled now and the difference
should allude to the problem.


On Wed, Jan 2, 2019 at 10:54 AM 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.
> Thanks,
> Justin
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190102/e80959ec/attachment.html>

More information about the llvm-dev mailing list