similar to: When a libcall will be generated?

Looks like I have run into the same issue reported in: https://bugs.llvm.org/show_bug.cgi?id=20871 Is there a fix or work-around for it? The bug report seems to be still open. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171005/46c1282d/attachment.html>

Ignore the suggested fix in my earlier post. How about this? diff --git a/lib/Target/X86/X86ISelLowering.cpp b/lib/Target/X86/X86ISelLowering.cpp index 20c81c3..b8ebf42 100644 --- a/lib/Target/X86/X86ISelLowering.cpp +++ b/lib/Target/X86/X86ISelLowering.cpp @@ -1632,10 +1632,11 @@ X86TargetLowering::X86TargetLowering(const X86TargetMachine &TM, if (!Subtarget.is64Bit()) { // These

> -----Original Message----- > From: Hal Finkel [mailto:hfinkel at anl.gov] > Sent: Tuesday, December 01, 2015 1:01 AM > To: Tim Shen > Cc: Gao, Yunzhong; llvm-dev at lists.llvm.org; Kit Barton; Nemanja Ivanovic > Subject: Re: [llvm-dev] Endianness for multi-word types > > ----- Original Message ----- > > From: "Tim Shen via llvm-dev" <llvm-dev at

Hi, I'm trying to emit FP_ROUND f64 -> f32 considering a mips target that only supports single float point operations. The problem is that f32 is considered legal on this target but f64 doesn't and the only way I can codegen this instruction is using setConvertAction(MVT::f64, MVT::f32, Expand), which issues a EmitStackConvert. What if I want a libcall instead? What should I do? The

On Wed, May 20, 2009 at 4:55 PM, Dan Gohman <gohman at apple.com> wrote: > Can you explain why you chose the approach of using a new pass? > I pictured removing LegalizeDAG's type legalization code would > mostly consist of finding all the places that use TLI.getTypeAction > and just deleting code for handling its Expand and Promote. Are you > anticipating something more

On May 20, 2009, at 1:34 PM, Eli Friedman wrote: > On Wed, May 20, 2009 at 1:19 PM, Eli Friedman > <eli.friedman at gmail.com> wrote: > >> Per subject, this patch adding an additional pass to handle vector >> >> operations; the idea is that this allows removing the code from >> >> LegalizeDAG that handles illegal types, which should be a significant

Hi Bruno, > I'm trying to emit FP_ROUND f64 -> f32 considering a mips target that > only supports single > float point operations. The problem is that f32 is considered legal on this > target but f64 doesn't and the only way I can codegen this instruction is using > setConvertAction(MVT::f64, MVT::f32, Expand), which issues a EmitStackConvert. > What if I want a

On Mon, 7 Jul 2008, Bruno Cardoso Lopes wrote: > I'm trying to emit FP_ROUND f64 -> f32 considering a mips target that > only supports single > float point operations. The problem is that f32 is considered legal on this > target but f64 doesn't and the only way I can codegen this instruction is using > setConvertAction(MVT::f64, MVT::f32, Expand), which issues a

On Mon, Nov 30, 2015 at 7:24 PM Gao, Yunzhong < yunzhong_gao at playstation.sony.com> wrote: > According to > http://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi.html, > "The high-order double-precision value (the one that comes first in > storage) must have the larger magnitude." > > So the order of the two doubles in your fp128 is not affected by the

Hi, I'm recently trying to investigate ppc_fp128 related problem. Here is a minimal C++ test case that seems wrongly compiled: long double id(long double a) { return a; } bool f(long double x) { return id(__builtin_fabsl(x)) >= 0; } int main() { if (f(-123.l)) { return 0; } return 1; } The program compiled with command: clang++ -static -target powerpc64le-linux-gnu bad.cc

For being able to change subtargets within a compilation unit, among other things, I need to be able to change the target lowering class that is used by BasicTTI For example we have a mips16 and non mips16 version. On the original call that creates this class, I'd like to pass the address of the address of the TargetLoweringBase class. That way I can insert a function pass before this

Just realized that BasicTransformInfoClass is an immutable pass. Not sure how to reconcile this with fact that there will be different answers needed depending on the subtarget. Seems like BasicTansformInfoClass should become a function pass that does not modify anything. On 03/22/2013 09:43 AM, Reed Kotler wrote: > Another way to do this would to be to have a reset virtual function >

Hello, my target has libcall support for long long shifts. I already have the following lines in my Lowering constructor: setLibcallName(RTLIB::SHL_I64, "__llshl"); setLibcallName(RTLIB::SRL_I64, "__llshru"); setLibcallName(RTLIB::SRA_I64, "__llshr"); and setOperationAction(ISD::SHL, MVT::i64, Expand); setOperationAction(ISD::SRA, MVT::i64,

Hi Reed, We will need to reconstruct the target machine and the TTI chain when the function attributes change. We currently don't have code for doing that but I suggest that you talk with Bill Wendling about the best way to implement this. Thanks, Nadav On Mar 22, 2013, at 11:30 AM, Reed Kotler <rkotler at mips.com> wrote: > Just realized that BasicTransformInfoClass is an

On Jun 23, 2008, at 5:35 AM, Richard Osborne wrote: > I'm trying to write a backend for a target with no hardware floating > point support. I've added a single i32 register class. I'm wanting all > floating point operations to be lowered to library function calls. For > the most part LLVM seems to get this right. For example > > define double @div(double %a, double

Another way to do this would to be to have a reset virtual function which is passed the Function, and the address of TLI so that it could be modified. This seems somewhat cleaner. The reset virtual function would be added to base class TargetLoweringBase. On 03/22/2013 09:22 AM, reed kotler wrote: > For being able to change subtargets within a compilation unit, among > other things, I

I'm trying to write a backend for a target with no hardware floating point support. I've added a single i32 register class. I'm wanting all floating point operations to be lowered to library function calls. For the most part LLVM seems to get this right. For example define double @div(double %a, double %b) { %result = fdiv double %a, %b ret double %result } is expanded to a

On 1 December 2015 at 13:41, Tim Shen via llvm-dev <llvm-dev at lists.llvm.org> wrote: > As a simple solution, when see a LLVM IR bitcast, instead of generating > (ISD::BITCAST x), can we generate (exchange_hi_lo (ISD::BITCAST x)) instead? An LLVM bitcast is defined to be equivalent to a store/load pair. Changing that for ISD::BITCAST would be very surprising, and I wouldn't

Evan Cheng wrote: > On Jun 23, 2008, at 5:35 AM, Richard Osborne wrote: > >> I'm trying to write a backend for a target with no hardware floating >> point support. I've added a single i32 register class. I'm wanting all >> floating point operations to be lowered to library function calls. For >> the most part LLVM seems to get this right. For example

Hello All, the patch below adds a target lowering hook to state that the target supports (or not) floating point exception behavior. The patch is small and contains one possible use for the hook (folding potentially exception raising fp operations). Any comments? Thanks Pedro -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: opensource1.txt