search for: convertnodetolibcall

...have to define custom library calls. How is the ideal way of implementing the custom library calls? Providing us with a target backend having a similar functionality would also help us significantly. Say for a i64 type compare, does adding it in the RuntimeLibcalls.def enum, SelectionDAGLegalize::ConvertNodeToLibcall function, and the target ISelLowering Class solve our problem? Is it okay to modify RuntimeLibcalls.def and SelectionDAGLegalize::ConvertNodeToLibcall function? A starting point for processing lib calls other than the ISelLowering class would also help! Thank you in advance for your help! Sincere...

...I am proposing for the Shifts. This is not just adding support for “out-of-tree-targets”, but giving consistency to the fact that we have perfectly defined LibCalls for Shifts, but they can’t be used because there’s an omission in the sources. I only proposed to add a missing case statement to the ConvertNodeToLibCall. To my understanding this is totally harmless to any existing or future targets because all what it does is to call the Library function when setOperationAction is set to “LibCall”. This is not different that any other case, and you just confirmed that you added the same for the CTLZ… functions....

...k anything: ultimately it’s the responsibility of the target to chose whether it uses it or not. Additionally, we should specify a way to fall through to LibCall lowering from a Custom lower implementation, if required or requested by the target. For example by providing a public path or a hook to ConvertNodeToLibCall, and/or by making the Custom implementation returning something that is recognised by the SelectionDAGLegalize code as a request for a LibCall fall through. Currently, the fall through mechanism after Custom lowering goes directly to the Expand code Yet another approach would be that LLVM would ex...

..._I32, "__ashrsi3") HANDLE_LIBCALL(SRA_I64, "__ashrdi3") However, setting setOperationAction(ISD::SRA, MVT::i16, LibCall); in the TargetLowering constructor causes LLVM to stop with an assert as the shift instruction can’t be selected. The problem is in SelectionDAGLegalize::ConvertNodeToLibcall because there’s no switch case for any of the Shift instructions. The problem gets solved by just adding switch cases like this (and similar for the other shift instructions): case ISD::SRA: Results.push_back(ExpandIntLibCall(Node, false, RTLIB::SRA_I...

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

Aside from the fact that you're checking for i64 specifically instead of generally checking for illegal types, how much of this is really PPC specific? Would this be a reasonable enhancement to the SDAG logic in general? -Hal On 1/4/19 8:03 AM, Nemanja Ivanovic wrote: The changes seem fine to me. I don't think this is excessively intrusive and it accomplishes what is needed by targets

Hi Nemanja, I'm attaching a patch that builds on D54583 and implements what we discussed on IRC earlier today. Particularly: * Make LowerCallTo() a virtual function, so it can be wrapped by a subclass. * Implement LowerCallTo() in PPCTargetLowering to wrap TargetLowering::LowerCallTo() and legalize the return node when targeting SPE. * Augment PPCTargetLowering::LowerCall_32SVR4() to

+ Eli Friedman as he often has very insightful comments regarding back end changes. On Fri, Jan 4, 2019 at 9:03 AM Nemanja Ivanovic <nemanja.i.ibm at gmail.com> wrote: > The changes seem fine to me. I don't think this is excessively intrusive > and it accomplishes what is needed by targets whose call lowering can > introduce illegal types. > Adding Justin Bogner as the

...problems you're seeing, but it should > be a small change to transform to the platform-specific SVML or other > intrinsics in the DAG. We already do this for mathlib calls on Linux for > example when we can use the finite versions of the calls. Have a look in > SelectionDAGLegalize::ConvertNodeToLibcall(): > > if (CanUseFiniteLibCall && DAG.getLibInfo().has(LibFunc_log_finite)) > Results.push_back(ExpandFPLibCall(Node, RTLIB::LOG_FINITE_F32, > RTLIB::LOG_FINITE_F64, > RTLIB::LOG_FINITE_...

Ashutosh, Thanks for the repy. Related earlier topic on this appears in the review of the SVML patch (@mmasten). Adding few names from there. https://reviews.llvm.org/D19544 There, I see Hal's review comment "let's start only with the directly-legal calls". Apparently, what we have right now in the trunk is "not legal enough". I'll work on the patch to stop

...problems you're seeing, but it should > be a small change to transform to the platform-specific SVML or other > intrinsics in the DAG. We already do this for mathlib calls on Linux for > example when we can use the finite versions of the calls. Have a look in > SelectionDAGLegalize::ConvertNodeToLibcall(): > > > > if (CanUseFiniteLibCall && DAG.getLibInfo().has(LibFunc_log_finite)) > Results.push_back(ExpandFPLibCall(Node, RTLIB::LOG_FINITE_F32, > RTLIB::LOG_FINITE_F64, > RTLIB::L...

...it should be a small change to transform to the > platform-specific SVML or other intrinsics in the DAG. We > already do this for mathlib calls on Linux for example when we > can use the finite versions of the calls. Have a look in > SelectionDAGLegalize::ConvertNodeToLibcall(): > >   > >     if (CanUseFiniteLibCall && > DAG.getLibInfo().has(LibFunc_log_finite)) >       Results.push_back(ExpandFPLibCall(Node, > RTLIB::LOG_FINITE_F32, >                                         RTLIB::LOG_FINIT...