similar to: Sincos for X86_64's GNUX32 and ARM's GNUEABI/GNUEABIHF enviroments

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

Hi all, We (Intel) would like to revive this thread on X32 ABI support upstreaming. X32 ABI homepage is here: https://sites.google.com/site/x32abi/ Currently x32 support is available in kernel/glibc/gcc/binutils and one can install for example Ubuntu 14 with extra x32 lib packages (apt-get install libc6-dev-x32) to evaluate x32-target code generated by GCC (gcc supports x32 on Ubuntu 14 out of

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

On Thu, 2013-08-22 at 12:29 +0400, Alexey Samsonov wrote: > 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

Hello, I was trying to compare the performance of icc, gcc and llvm on the program almabench.c in Coyote Benchmark suite. Here is a line of code from the program. da = da + (ca[np][k] * cos(arga) + sa[np][k] * sin(arga)) * 0.0000001; gcc and icc are performing way better than llvm as they are using 'sincos' library function to compute the sin and the cos of the argument in a

Hi Suresh, > I was trying to compare the performance of icc, gcc and llvm on the > program almabench.c in Coyote Benchmark suite. Here is a line of code > from the program. > > > da = da + (ca[np][k] * cos(arga) + sa[np][k] * sin(arga)) * 0.0000001; > > gcc and icc are performing way better than llvm as they are using > 'sincos' library function to

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

Hi, I'm looking at http://llvm.org/bugs/show_bug.cgi?id=13204 which involves converting calls to sin and cos to sincos (when available) Initially I thought about transforming calls to sinf/cosf to sincosf. However, I don't think this is a legal transformation given that a declaration for a function called sinf is not necessarily the standard library function. Therefore it makes sense to

On Thu, 2013-08-22 at 11:29 +0400, Alexey Samsonov wrote: > Ah, I've replied in a different thread already. What Dmitri says - If > you're interesting in only building the Clang on x32 host, you may avoid > checking out compiler-rt repo for now. > > compiler-rt does make a convenient compiler test though.. :) fatal error: error in backend: Cannot select: 0x30ccf38: ch =

On 22/01/13 05:30, Redmond, Paul wrote: [...] > I'm looking at http://llvm.org/bugs/show_bug.cgi?id=13204 which involves converting calls to sin and cos to sincos (when available) > > Initially I thought about transforming calls to sinf/cosf to sincosf. However, I don't think this is a legal transformation given that a declaration for a function called sinf is not necessarily the

Hi David, On 2013-01-22, at 5:59 AM, David Given wrote: > ...and the code that actually does it is here: > > lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp > > Look for SelectionDAGBuilder::visitUnaryFloatCall() and visitCall(). > > It appears that such functions are only promoted if they're declared > readnone, which provides some protection against overriding

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

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 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 Sanjay, For sincos calls, I’m currently just going through isTriviallyVectorizable(), which was good enough to get things working so that I could test the translation. I don’t see why this cannot be changed to use addVectorizableFunctionsFromVecLib(). The other functions that I’m working with are already vectorized using the loop pragma. Those include sin, cos, exp, log, and pow. From: Sanjay

RFC: A proposal for vectorizing loops with calls to math functions using SVML (short vector math library). ========= Overview ========= Very simply, SVML (Intel short vector math library) functions are vector variants of scalar math functions that take vector arguments, apply an operation to each element, and store the result in a vector register. These vector variants can be generated by the

Ah, I've replied in a different thread already. What Dmitri says - If you're interesting in only building the Clang on x32 host, you may avoid checking out compiler-rt repo for now. On Thu, Aug 22, 2013 at 10:59 AM, Dmitri Gribenko <gribozavr at gmail.com>wrote: > On Wed, Aug 21, 2013 at 11:04 PM, Steven Newbury <steve at snewbury.org.uk> > wrote: > > I've

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

Viswanath Puttagunta wrote: > Can we please have review on RFCv2? We have quite a few optimizations > (Eg: ifft/mdct_backwards, fixed point fft/ifft mdct_forward/backward > etc) that are in my pipeline that depend on this patch series being > accepted. So, trying to make progress on this... On an armv7l board running Ubuntu, you've broken the build with just --enable-intrinsics

Hi Guys, In LLVM codegen, a typical binary operation instruction is defined something like below: " def _rr: NVPTXInst<(outs Int1Regs:$dst), (ins Int1Regs:$a, Int1Regs:$b), "xor.pred \t$dst, $a, $b;", [(set Int1Regs:$dst, (OpNode Int1Regs:$a, Int1Regs:$b))]>; “ which takes two inputs and write the result to the $dst register. Then how to define a binary