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

Justin Hibbits via llvm-dev llvm-dev at lists.llvm.org
Wed Jan 2 09:34:16 PST 2019

Hi Nemanja,

The behavior is the same prior to my patch and with my patch, with regard to this specific behavior. The custom BITCAST lowerer doesn't introduce any change with this. In fact, it was reported on https://reviews.llvm.org/D49754 as behavior introduced with the original SPE additions, so is inherent in this target from the beginning. So, it seems to me that the new nodes added in the libcall lowering should themselves be lowered, unless I should do as Alex alluded to, and add new legal nodes that themselves handle the argument splitting and reforming. But it seems to me that the machinery to do that already exists, but might need another pass?

On Wed, 2 Jan 2019 11:39:59 -0500 Nemanja Ivanovic <nemanja.i.ibm at gmail.com> wrote:

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 buildpair 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. N 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 buildpair i32, > i32)' into a 'f64 BUILDSPE64 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 > BUILDPAIR 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 = buildpair 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 >

More information about the llvm-dev mailing list