similar to: [LLVMdev] ARM ATPCS ABI support

On Jun 24, 2011, at 12:52 PM, Alasdair Grant wrote: >> Both NetBSD and FreeBSD seems to use older ATPCS ABI standard. >> As I can see it is not supported in LLVM. >> >> Seems that ATPCS is predecessor of AAPCS so I wonder how easy is >> to implement it in LLVM/Clang... >> >> Is it worth efforts? Any thoughts? > > See

> Both NetBSD and FreeBSD seems to use older ATPCS ABI standard. > As I can see it is not supported in LLVM. > > Seems that ATPCS is predecessor of AAPCS so I wonder how easy is > to implement it in LLVM/Clang... > > Is it worth efforts? Any thoughts? See http://gcc.gnu.org/ml/gcc/2010-05/msg00468.html : "Do they still want their OS to work on modern CPUs with any

Hi, I'm working on bringing up complete coverage for a Gentoo x32 "desktop" system. I've been cooking up quite a few patches for various packages to push upstream, but right now, the biggest blocker is the lack of support for building with/codegen targeting x32 in llvm/clang. Since the x32 patches were sent last year, I see support code has landed in LLVM, and basic handling of

Clang patch for X32 support. Applies against current trunk. --- ./tools/clang/include/clang/Driver/Options.td.orig 2013-05-16 21:51:51.286129820 +0000 +++ ./tools/clang/include/clang/Driver/Options.td 2013-05-16 21:53:24.875004239 +0000 @@ -841,6 +841,7 @@ HelpText<"Enable hexagon-qdsp6 backward compatibility">; def m3dnowa : Flag<["-"], "m3dnowa">,

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

---------------------------------------- > Date: Thu, 23 Apr 2015 09:33:58 -0700 > Subject: Re: [LLVMdev] question about alignment of structures on the stack (arm 32) > From: t.p.northover at gmail.com > To: alexey.perevalov at hotmail.com > CC: llvmdev at cs.uiuc.edu; lubos at dolezel.info > >>> void func(int x, long long y) >>> >>> iOS will pass y in

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

Hello Tim, thanks for response ---------------------------------------- > Date: Mon, 20 Apr 2015 11:45:03 -0700 > Subject: Re: [LLVMdev] question about alignment of structures on the stack (arm 32) > From: t.p.northover at gmail.com > To: alexey.perevalov at hotmail.com > CC: llvmdev at cs.uiuc.edu > > On 20 April 2015 at 11:09, Alexey Perevalov > <alexey.perevalov at

This patch is still not creating elf32_x86_64 objects. No idea why. :( It does however, fix elf_x86_64 (-m64) code generation on x32 hosts which is nice. :) --- ./tools/clang/include/clang/Driver/Options.td.orig 2013-05-16 21:51:51.286129820 +0000 +++ ./tools/clang/include/clang/Driver/Options.td 2013-05-16 21:53:24.875004239 +0000 @@ -841,6 +841,7 @@ HelpText<"Enable hexagon-qdsp6

On 07/16/2014 11:45 AM, Tim Northover wrote: >>> As has been mentioned several times (*), LLVM and GCC setup frame pointer to >> point to different stack slots on ARM. GCC's fp points to stack slot holding >> lr while LLVM's fp points at the next slot. > > This looks flipped from my tests. Both create an { fp, lr } struct; > GCC sets current fp to the address

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

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

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

---------------------------------------- > Date: Tue, 21 Apr 2015 09:15:02 -0700 > Subject: Re: [LLVMdev] question about alignment of structures on the stack (arm 32) > From: t.p.northover at gmail.com > To: alexey.perevalov at hotmail.com > CC: llvmdev at cs.uiuc.edu > >> I'm using MachO loader (https://github.com/LubosD/darling/). I'm trying to make it work on

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

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

Hello, Last year I tried --- and failed --- to generate float-heavy ARM code via the JIT on an armhf platform. No matter what I did, it would always generate armel code instead. This was on LLVM 3.2, which was all that was available then. Now I'm running into a requirement to do this again: while it's much less crashy than it was, I still can't seem to persuade the JIT to generate

> 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

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 >