Displaying 20 results from an estimated 3000 matches similar to: "[LLVMdev] ARM EABI and modulo"
2013 Dec 09
0
[LLVMdev] [cfe-dev] ARM EABI and modulo
Hi Joerg,
> At the moment, this will call __modsi3 and __umodsi3, even though those
> functions are not part of AAPCS. Should this be considered a lowering
> bug in the ARM target?
LLVM actually supports both variants, depending on the target. The
__aeabi_* functions are part of the ARM "runtime ABI" and largely
independent of AAPCS. For whatever reason, Linux (& Darwin)
2013 Dec 09
3
[LLVMdev] [cfe-dev] ARM EABI and modulo
On Mon, Dec 09, 2013 at 07:56:26AM +0000, Tim Northover wrote:
> Hi Joerg,
>
> > At the moment, this will call __modsi3 and __umodsi3, even though those
> > functions are not part of AAPCS. Should this be considered a lowering
> > bug in the ARM target?
>
> LLVM actually supports both variants, depending on the target. The
> __aeabi_* functions are part of the
2013 Dec 09
3
[LLVMdev] [cfe-dev] ARM EABI and modulo
On Mon, Dec 09, 2013 at 01:58:29PM +0000, Renato Golin wrote:
> I can see the error, and it's just a bad selection of choices. I was
> wrong in assuming that the "eabi" at the end would always force it:
>
> $ clang -target arm-elf-eabi -S mod.c -o - | grep mod
> .file "mod.c"
> bl __modsi3
> bl __umodsi3
I was discussing this with Tim on IRC and he
2013 Dec 09
0
[LLVMdev] [cfe-dev] ARM EABI and modulo
On 9 December 2013 11:51, Joerg Sonnenberger <joerg at britannica.bec.de> wrote:
> Part of the concern is that the same code using / does call __aeabi_idiv
> and __aeabi_uidiv.
Hi Joerg,
I can see the error, and it's just a bad selection of choices. I was
wrong in assuming that the "eabi" at the end would always force it:
$ clang -target arm-elf-eabi -S mod.c -o - |
2013 Dec 09
0
[LLVMdev] [cfe-dev] ARM EABI and modulo
On Mon, Dec 09, 2013 at 03:11:45PM +0100, Joerg Sonnenberger wrote:
> On Mon, Dec 09, 2013 at 01:58:29PM +0000, Renato Golin wrote:
> > I can see the error, and it's just a bad selection of choices. I was
> > wrong in assuming that the "eabi" at the end would always force it:
> >
> > $ clang -target arm-elf-eabi -S mod.c -o - | grep mod
> > .file
2013 Dec 11
1
[LLVMdev] [PATCH] Select correct embedded libclang_rt on Darwin
> 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
2016 Apr 10
3
compler-rt, __aeabi_memcpy () possibly broken (ARM)
Hello,
I recognized that compiler-rt's the implementation of __aeabi_memcpy
simply branches to memcpy.
The implementation of memcpy is not provided. So an externally provided
memcpy () has to be used.
(also applies to memmove, memset, memclr)
On ARM I have seen implementations of memcpy () using floating-point
registers (if compiled with NEON support). The is perfectly
legal, as memcpy ()
2014 Sep 06
2
[LLVMdev] [Compiler-RT] [ARM] Where __aeabi_[il]div0 builtins should be implemented?
> Looks as though whomever implemented the call to __aeabi_idiv0 wanted
> to be conservative for non EABI targets.
How could it prevent him from providing default implementation of
__aeabi_idiv0() for EABI targets?
> AFAIK, gnueabi targets recognize all EABI functions, so that should
> work well.
Not sure I understand you, nothing in compiler-rt defines these
functions, they are
2012 Jan 09
0
[LLVMdev] generating ELF files on non-ELF platforms with MC
Hi,
> Would it be OK to add "ELF" to Triple::EnvironmentType? It seems like a
plausible choice since MachO is there. On the other hand, I'm not sure
whether it makes sense to make it mutually exclusive with the other members
of EnvironmentType (GNU, GNUEABI, EABI).
EABI and GNUEABI imply ELF. GNU in practice does not need to imply ELF, but
is used in the ARM world as "the
2012 Jun 19
0
[LLVMdev] Is cross-compiling for ARM on x86 with llvm/Clang possible?
Hello
> ./clang -v -emit-llvm -ccc-host-triple arm-none-linux-gnueabi
> -I/home/hum/Documents/Projects/llvm_clang/gnuarm-4.0.2/arm-elf/include
> -L/home/hum/Documents/Projects/llvm_clang/gnuarm-4.0.2/arm-elf/bin hello.c
You forgot about sysroot here.
> /home/hum/Documents/Projects/llvm_clang/gnuarm-4.0.2/arm-elf/bin/ld:
> unrecognised emulation mode: armelf_linux_eabi
>
2012 Jan 09
1
[LLVMdev] FW: generating ELF files on non-ELF platforms with MC
Ping,
Apart from Anton's concerns (which I think are manageable) and Micah's support, I received no reply on this.
Does there exist a way to tell MC to generate and ELF container for code on Windows? If not, I'm willing to submit a patch to fix this, but would like some opinions on the best direction to take here.
The proposed "llvm::TargetSpec class"
2012 Jun 19
2
[LLVMdev] Is cross-compiling for ARM on x86 with llvm/Clang possible?
Hello Gergö, Joerg and people on our list
With your kind answer, I tried to build a hello world program for
ARM(arm-none-linux-gnueabi) on my x86-64 PC.
Thank you we verified the generated bitcode. The only thing remained is
linking.
Let me brief what I did so far.
1. Built Clang/llvm in a way explained in
http://clang.llvm.org/get_started.html on Ubuntu 11.10 x86-64 PC
2. Downloaded gcc-4.0
2012 Jan 04
4
[LLVMdev] generating ELF files on non-ELF platforms with MC
Hello,
We're currently working on MC-JIT, focusing on runtime generation and loading of ELF object files, even on non-ELF platforms (i.e. Windows). However, we run into a problem with MC insisting to generate COFF objects on Windows, MachO on Macs and ELF only otherwise, based on the triple.
Is there an existing method to generate ELF objects with MC on Windows, without modifying MC?
Thanks
2012 Aug 06
2
[LLVMdev] ARM eabi calling convention
When I compile this program
*$ cat vararg1-main.c
typedef struct {
double d;
} S0;
S0 g1;
void foo0(int a, ...);
int main(int argc, char **argv) {
S0 s0 = { 2.0 };
foo0(1, s0);
printf("%f\n", g1.d);
* * return 0;
}*
with this command,
*$ clang -target arm-none-linux-gnueabi-gcc -ccc-clang-archs armv7
-emit-llvm vararg1-main.c -S -o vararg1-main.ll -O3*
I get this
2014 Jun 17
4
[LLVMdev] triples for baremetal
[+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
2013 Nov 26
3
[LLVMdev] Targeting ARM Cortex-a9 from x86_64 with clang
Hi, here's the canonical helloworld.c
#include<stdio.h>
int main()
{
printf("Hello World");
return 0;
}
In accordance with the cross-compilation LLVM documentation [1], I am
trying to target the ARM on the Zedboard [2]. It is an ARM Cortex-A9.
The machine I am compiling on is an x86_64 Fedora Linux machine, using
clang 3.3. I am failing to generate an executable,
2014 Jun 19
2
[LLVMdev] [PATCH] triples for baremetal
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
2010 Sep 17
2
[LLVMdev] Support for ARM Run-Time ABI
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
2007 May 14
3
[LLVMdev] llvm 2.0 release announcement [draft]
Hi Everyone,
It is getting to be that time again. I've scoured llvm-commits and
collected a list of some of the major features we've developed since
the last status update (from Feb 21). Please take a look and send me
(off list) additions, feedback, corrections, etc. As usual, if I
missed something, it's probably because there is such a huge amount
of stuff happening,
2011 Jan 22
2
[LLVMdev] Target Triple Changes
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