similar to: [LLVMdev] Support for ARM Run-Time ABI

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

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 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

On 22 March 2017 at 01:38, Friedman, Eli <efriedma at codeaurora.org> wrote: >> Small example fail.c: >> >> // clang -O2 -target armv7a-none-none-eabi -mfloat-abi=hard -ffast-math >> -S fail.c -o - >> extern float sinf (float x); >> float sin1 (float x) {return (sinf (x));} I changed your example slightly to make sure we're passing the

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 all, There's been some controversies in the TargetTriple changes and I want to explain it better in the list (to a wider audience) and also propose my plans on how to support the ARM platform better, especially cross-compilation in Clang. All this discussion came as a spin-off of bug 8911 (http://llvm.org/bugs/show_bug.cgi?id=8957)... Today we have three major problems in cross-compiling

Hi Renato, > 1. Some ARM triples "arm*-none-eabi" don't get properly recognized, > so Clang doesn't generate correct AAPCS (soft and hard) calls and > don't pass the correct triple to LLC. in order to have "eabi" be properly recognized by LLVM, it is enough to add "eabi" as a valid environment value. Then Triple::Normalize will automatically

On Mon, Oct 5, 2009 at 2:21 PM, Rafael Espindola <espindola at google.com> wrote: > 2009/10/4 Sandeep Patel <deeppatel1987 at gmail.com>: >> There needs to be a build step >> somewhere in llvm-gcc that copies it into libexec/<gcc >> poop>/libLLVMgold.so, but I've been doing that manually for now. > > Yes, this is bad. The problem is that we build

Eric, Attached are patches for llvm and clang that implement this. I've made 'none' a component that must be added explicitly (i.e. don't turn arm-eabi into arm--none-eabi, but rather turn it into arm--unknown-eabi) to try to reduce surprises. It also keeps the normalization logic a bit simpler than it would otherwise have to be. SPIR triples were one place where I was

On May 9, 2011, at 1:41 PM, Renato Golin wrote: [snip] > One example is the struct byval. The ARM back-end still doesn't > support struct byval (maybe now it does, I was away for a while), The ARM backend now supports struct byval for APCS. Extending it to support AAPCS shouldn't be too difficult. Alas, I won't have time to revisit this in the near future. stuart

On 29 March 2017 at 02:33, Saleem Abdulrasool <compnerd at compnerd.org> wrote: > sin/cos are libm functions, and so a libcall to those need to honour the > floating point ABI requests. The calling convention to be followed there > should match `-mfloat-abi` (that is, -mfloat-abi=hard => AAPCS/VFP, > -mfloat-abi=soft => AAPCS). Exactly, but they're not, and that's

On Wed, May 11, 2011 at 11:42 PM, Stuart Hastings <stuart at apple.com> wrote: > > On May 9, 2011, at 1:41 PM, Renato Golin wrote: > > [snip] > >> One example is the struct byval. The ARM back-end still doesn't >> support struct byval (maybe now it does, I was away for a while), > > The ARM backend now supports struct byval for APCS.  Extending it to

> * 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 Mon, Oct 5, 2009 at 8:04 PM, Rafael Espindola <espindola at google.com> wrote: >> I have no idea how to reduce this. >> >> Configure llvm-gcc for "arm-eabi" and use "--with-cpu=cortex-a8 >> --with-fpu=neon --with-abi=aapcs --with-float=hard". The triple in the >> bitcode will be "armv7-eabi" but the actual CPU subtarget won't

[+llvmdev, -llvm-dev] (Oopsies, llvmdev doesn't have a hyphen in it like all the others do) On 6/17/14, 10:45 AM, Jonathan Roelofs wrote: > [+llvm-dev, cfe-dev] > > Was "Re: [PATCH] ARM: allow inline atomics on Cortex M" > > On 6/17/14, 10:42 AM, Jonathan Roelofs wrote: >> >> >> On 6/17/14, 9:35 AM, Renato Golin wrote: >>> On 17 June 2014

Hi Chandler, That's embarrassing how weird this part of clang is. I have a provisional patch which fixes the problem but underlines clang's problems. I will submit it tonight for comments. суббота, 18 октября 2014 г. пользователь Chandler Carruth написал: > > On Fri, Oct 17, 2014 at 7:51 AM, Anton Korobeynikov < > anton at korobeynikov.info >

Attached is the patch I've been building arm-eabi with, which might help with linux-gnueabi. I disable multilib to get around several bugs with thumb. I build cross binutils first, then llvm, then llvm-gcc with newlib merged in. The following bugs need to be addressed for these non-Darwin ARM targets: 1388 2313 2545 2985 deep On Fri, Mar 13, 2009 at 12:30 AM, Misha Brukman <brukman at

On Dec 18, 2008, at 7:05 PM, Sandeep Patel wrote: > Since there have been no answers, I will have to start at the > beginning. > > One of the first changes I'd like to try is adding the additional > registers and the AAPCS VFP variant calling conventions. Is there a > reason why the ARM Target isn't using the CCState machinery? Please clarify. I am not sure what you

Forgot to reply all to include the list. deep ---------- Forwarded message ---------- From: Sandeep Patel <deeppatel1987 at gmail.com> Date: 2010/11/17 Subject: Re: [LLVMdev] Build Attributes Proposal To: Rafael Espíndola <rafael.espindola at gmail.com> 2010/11/17 Rafael Espíndola <rafael.espindola at gmail.com>: >> Another use for build attributes would be as a means

Is anybody actively working on additional ARM target support? I need Cortex support (ARMv7, VFPv3, and Neon). Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20081205/3756d719/attachment.html>