search for: eabihf

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

...ation will > > also be used to fix the N32 support for IAS. > > I would be perfectly fine with this if instead of just hitting an > wildcard these different triples actually meant different things to > binutils. That doesn't seem necessary since 'gnueabi' and 'gnueabihf' seem to be matched by a 'gnu*' wildcard too but I'm in favour of defining these triples in binutils if that's necessary to fix LLVM. I'd appreciate it if this patch series didn't have to wait until the triples are present in the binutils source though. Are you ok with u...

On 24 June 2016 at 06:02, Daniel Sanders <Daniel.Sanders at imgtec.com> wrote: > Hi, > > Having recently enabled IAS by default for the MIPS O32 ABI, I'm now trying to do the same thing for the MIPS N64 ABI. Unfortunately, it is not currently possible to enable IAS by default for the N64 ABI without also enabling it for the N32 ABI because this information is not reflected in

Hi, I do not get your result. Do I miss something? $COMP_ROOT/clang++ --target=arm-arm-eabihf -march=armv8.2a+fp16 arm.cpp -S -o - -O3 .text .syntax unified .eabi_attribute 67, "2.09" .eabi_attribute 6, 14 .eabi_attribute 7, 65 .eabi_attribute 8, 1 .eabi_attribute 9, 2 .fpu crypto-neon-fp-armv8 .eabi_attribute 12, 4 .ea...

Dear list, git checkout llvmorg-8.0.0 -b llvm8.0 cmake -G "Unix Makefiles" ../llvm-project/llvm -DCMAKE_BUILD_TYPE=Debug -DLLVM_ENABLE_PROJECTS="clang;lld" -DLLVM_TARGETS_TO_BUILD="X86;NVPTX;AMDGPU;ARM;AArch64" [arm.cpp] #define vst4_lane_f16(__p0, __p1, __p2) __extension__ ({ \ float16x4x4_t __s1 = __p1; \ __builtin_neon_vst4_lane_v(__p0, __s1.val[0],

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

On 7/23/14, 1:20 PM, Tim Northover wrote: [...] > You should probably be specifying a triple directly, and making it an > AAPCS-VFP one for good measure: "armv7-linux-gnueabihf" for example, > or "thumbv7-none-eabihf". You shouldn't even need to set FloatABI for > those two. How do I do this? (I can't find any examples, and the API is decidedly unclear...) -- ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ───── │ "Feminism encourages...

...#39;ll leave this for another thread. From: Eric Christopher [mailto:echristo at gmail.com] Sent: 01 July 2016 23:05 To: Daniel Sanders; llvm-dev at lists.llvm.org Cc: rafael.espindola at gmail.com; Matthew Fortune Subject: Re: Representing MIPS ABI information in the triple as ARM/X86 do for EABI/EABIHF/X32 Hi Daniel, While I'm sympathetic to the amount of work associated this appears to be attempting to work around an API problem by changing triples needlessly. There's already some ABI support in MCTargetOptions that I used when fixing up the ARM port a while back and this use can eithe...

On 7/23/14, 3:30 PM, Tim Northover wrote: [...] > It looks like it's a case of calling Module::setTargetTriple. As with > most JIT setup questions, though, often the best way to find out is to > get something working in lli and then look at what it does > (tools/lli/lli.cpp). Well, it's *almost* working --- hardfloat code is now being generated, and it even seems to be right

...-EB/etc. The approach I'm using is to encode the ABI information into the triple in the same way that ARM does for EABI and hardfloat, and the same way that X86 does for X32. These targets define variants of Triple::GNU for each of these ABI's in the form of the Triple::GNUEABI, Triple::GNUEABIHF, and Triple::GNUX32 values of the environment component of the triple and it's up to the frontend and/or API-user to pass the right thing to the backend. For MIPS, I'm defining Triple::GNUABI32, Triple::GNUABIN32, and Triple::GNUABI64. All three of these are supported by tools like binutil...

Hello, clang/llvm 4.0.0 generates invalid calls for builtin functions with -mfloat-abi=hard -ffast-math. 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));} generates code to pass the parameter in r0 and expect the result in r0. The same code without

Hello LLVM-Dev, Most of the processing for i64 and f64 types for our backend are emulation library calls. Some of the library calls are not defined in the RuntimeLibcalls.def Libcall enum so we have to define custom library calls. How is the ideal way of implementing the custom library calls? Providing us with a target backend having a similar functionality would also help us significantly. Say

On 7/24/14, 7:18 AM, Tim Northover wrote: [...] > Which triple are you using? And is the correct code used when you run > the same IR through "llc -mtriple=whatever"? armv7-linux-gnueabihf, as suggested; and if I use llc -mtriple then the code compiles to: vstr s0, [r0] bx lr ...which I would consider correct. (What's more interesting is *without* specifying the triple llc generates armel code. Should llc default to generating code which will actually run on a given platfor...

...omponents and > application wrappers for CC=foocc" and off you go. > The produced wrappers look exactly like a normal cross-toolchain. The > tuple is the same as what NetBSD uses, except with rumprun added in the > middle, so e.g. x86_64-rumprun-netbsd or arm-rumprun-netbsdelf-eabihf. Great, I think this solves a large problem (whether its a wrapper or a "proper cross compiler" I think is of limited importance as long as it behaves enough like the latter) > I don't really have good solutions for the packaging problem. Building > a "full distro&quot...

...s of the specs into the wrappers, or whatever equivalent clang uses. (patches welcome ;) The produced wrappers look exactly like a normal cross-toolchain. The tuple is the same as what NetBSD uses, except with rumprun added in the middle, so e.g. x86_64-rumprun-netbsd or arm-rumprun-netbsdelf-eabihf. That naming scheme means that most GNU-using software compiles nicely for Rumprun just by running configure as ./configure --host=x86_64-rumprun-netbsd followed by "make". Sometimes you additionally need things like --disable-shared, but all in all everything works pretty well. Se...

On Thu, Aug 22, 2013 at 11:56 AM, Steven Newbury <steve at snewbury.org.uk>wrote: > On Thu, 2013-08-22 at 11:50 +0400, Alexey Samsonov wrote: > > On Thu, Aug 22, 2013 at 11:39 AM, Steven Newbury <steve at snewbury.org.uk > >wrote: > > > > > On Thu, 2013-08-22 at 11:27 +0400, Alexey Samsonov wrote: > > > > Hi Steven, > > > > > >

On Thu, 2013-08-22 at 11:50 +0400, Alexey Samsonov wrote: > On Thu, Aug 22, 2013 at 11:39 AM, Steven Newbury <steve at snewbury.org.uk>wrote: > > > On Thu, 2013-08-22 at 11:27 +0400, Alexey Samsonov wrote: > > > Hi Steven, > > > > > > This looks interesting and raises a number of questions :) > > > > > > 1) Does applying this patch

Xen upstream BoF ================ We had a discussion around Xen and packaging at Debian's annual developer conference (Debconf) a few weeks back: https://summit.debconf.org/debconf15/meeting/279/xen-upstream-bof/ These are my notes, I think there is probably stuff of interest to most distro people, not just Debian folks. The session was scheduled in a small, out of the way, room. Around 2

Hello LLVM Developers, Within Google, we have a growing range of needs that existing libc implementations don't quite address. This is pushing us to start working on a new libc implementation. Informal conversations with others within the LLVM community has told us that a libc in LLVM is actually a broader need, and we are increasingly consolidating our toolchains around LLVM. Hence, we