similar to: [LLVMdev] [PATCH] Support for ARM Run-Time ABI (FP and Integer helper functions)

On Mon, Sep 27, 2010 at 5:02 PM, Evzen Muller <evzen.muller at arm.com> wrote: > > To make it easier to review & commit I have split and cleaned-up our > original > "Support for ARM Run-Time ABI" patch, this part adds support for calls which > > can be mapped using setLibcallName. As noted in the earlier thread on this, I'm pretty sure that we need to

I wrote that loop. :-) So now the differences between this patch and the one I had been sitting on are: * We have opposite condition codes in our FP comparisons. * This patch has integer division, which seems like a good thing, but wasn't needed for my A9 target. Are you sure about the comparisons? deep On Tue, Sep 28, 2010 at 9:11 AM, Evzen Muller <evzen.muller at arm.com> wrote:

Hi Anton, could you please look at the second part of RTABI patch (support for REM/UREM) I sent yesterday? http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20100927/108762.html Thanks Evzen >> I guess I never saw a float cmp libcall in my testing, which makes >> sense for the platforms I was testing on. >> >> LGTM then. >I will apply the patch

> * We have opposite condition codes in our FP comparisons. No, Evzen is correct. The condcode is used to test the libcall result against zero and EABI libcalls return 1 in case of "true" result of the comparison, thus we have to invert the condcode agains the default value. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State

On Tue, Sep 28, 2010 at 9:24 PM, Anton Korobeynikov <anton at korobeynikov.info> wrote: >> * We have opposite condition codes in our FP comparisons. > No, Evzen is correct. The condcode is used to test the libcall result > against zero and EABI libcalls return 1 in case of "true" result of > the comparison, > thus we have to invert the condcode agains the default

Hi Sandeep, On 17 September 2010 18:52, Sandeep Patel <deeppatel1987 at gmail.com> wrote: > * Only these few renamed libcalls are set as AAPCS because other > libcalls may still want to be AAPCS-VFP. Even the F32 ones? Anton, As discussed, we might better put the FP helpers first, then deal with the REM and Memset later. If Sandeep's patch passes all tests, you can apply that

On Tue, Sep 9, 2014 at 1:37 AM, Renato Golin <renato.golin at linaro.org> wrote: > On 9 September 2014 02:18, Saleem Abdulrasool <compnerd at compnerd.org> > wrote: > > The current implementations actually return 0. Can you point out where > that > > doesn't hold please? > > With the current implementation... > > int foo(int a) { > return

On Mon, Sep 8, 2014 at 1:19 AM, Renato Golin <renato.golin at linaro.org> wrote: > > Why not adjust this instead? > > I was just being conservative. I don't know what else depends on this > library and I don't want to change things outside of my scope. > The current implementations actually return 0. Can you point out where that doesn't hold please? If you

On 11 April 2016 at 02:43, Renato Golin via llvm-dev <llvm-dev at lists.llvm.org> wrote: > This is standard AAPCS, I trully hope neither glibc, newlib or musl's > implementations will corrupt anything more. Normal AAPCS functions are allowed to corrupt d0-d7 and d16-d31, but the RTABI seems pretty explicit that these functions aren't. I think we've got a real problem here.

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

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,

On Sat, Jan 7, 2012 at 10:18 AM, Johannes Birgmeier <e0902998 at student.tuwien.ac.at> wrote: > 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"); >  

Tim, Are you referring to setLibcallName? That is target specific yes but there isn't RTLIB for most of the libm functions, for example, for acos this doesn't apply. Ideally what I would like is to create a libc with functions like acos called something like __xxx_acos that can still be recognized to be optimized. RTLIB is pretty limited but it works fine, I can just use

> When you decide to work on MachO/Darwin, I want to discuss the problems with ELF vs. EABI (http://llvm.org/PR18187). Well, I'm doing it now to some extent (working on disentangling the ARM backend's various uses of isTargetIOS, isTargetDarwin, isMoonFull as a starting-point). The thing is, the main advantage of Triples is that they're largely GCC-compatible. Without that

On 2/16/2016 8:44 AM, Konstantin Vladimirov via llvm-dev wrote: > > CI->getArgOperand(0) returns operand with type (double*) rather then > double, because in our ABI doubles are passed via memory. The LLVM intrinsics in the LLVM IR must conform to whatever the IR's requirements are. That means that even in the case of your backend, the arguments to the intrinsic must be doubles,

Attached is an earlier patch I've been sitting on for clearly way too long. There are a few differences worth discussing: * Only these few renamed libcalls are set as AAPCS because other libcalls may still want to be AAPCS-VFP. * I have all the comparison CCs backward from you. I don't know offhand which is correct. * I put in the long long libcalls as well. Any or all of these

Dear all, I just sent a patch to llvm-commits about ARM RT-EABI support when choosing "arm/thumb*-eabi-*" triple. It involves three changes described in the path: 1. Floating point helpers (instead of GNU ones). This is supported by GCC as well, in EABI mode. 2. Reminder lowering, using ABI helper too. 3. Memset, changing the order of arguments, as required by the ABI. Please

On Tue, Jun 7, 2016 at 1:57 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > Tim, > > Currently, I have to do multiple things: > > 1) create some setLibcallNames in XXXISelLowering.cpp to generate correct > naming for RTLIBS. > 2) lower ISD down to an RTLIB for some calls (and then do solution 1 on > those to get correct names) These solve a related but different -

If I do T.getArch() == xxx TLI.setUnavailable(LibFunc::copysign) then this works at generating a call instead of not being able to select the ISD::FCOPYSIGN, but I don't know why I don't need to do this for other LibFunc functions (such as floor, etc... these generate call just fine)? Thanks, Ryan On Tue, Jun 14, 2016 at 11:58 AM, Ryan Taylor <ryta1203 at gmail.com> wrote:

The LLVM IR reference manual states, for fptosi: "The ‘fptosi’ instruction converts its floating-point <http://llvm.org/docs/LangRef.html#t-floating> operand into the nearest (rounding towards zero) signed integer value." I interpreted this to mean that it rounds: The nearest integer to 0.3 is 0. The nearest integer to 0.9 is 1. The nearest integer to 0.5 is either 0 or 1. And