similar to: [LLVMdev] How to set default target flags?

Hello, I've built LLVM natively on a fpu-less (soft-float) mips32 target, and built mesa to use it. However llvm apparently cannot determine what machine it's running on and builds code for a generic mips target with fpu. Is there a way to have llc/llvm always use "-march=mipsle -mcpu=mips32 -mattr=+soft-float" as a default command line, something similar to gcc's

Hi Tim, Ohh, I completely forgot to attach the source. Running this with: $ llc -O2 -mcpu=generic HeapStackCheck.ll -mattr=+soft-float -o HeapStackCheck.s results in 0 llc 0x000000010fea65e6 llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 37 1 llc 0x000000010fea5b3a llvm::sys::RunSignalHandlers() + 83 2 llc

Thanks andrew for the answer. I would like to generate code for Cortex-A9 that don't use neon for fp computation but vfpv3 -d16. I've tried some combination of -mattr=+neon,-neonfp,+vfp3,+d16 but couldn't get ".fpu vfpv3-d16" directive generated in assembly file. Do you know how to make it happen ? Best Regards Seb From: Andrew Trick [mailto:atrick at apple.com] Sent:

Hi Eli, Renato, Thanks for your feedback, there's a lot more to some of these things than I knew. I've addressed your points below. The overall summary is: - Start with converting the TargetParser to tableGen, with no user facing changes - Add warnings based on that, behind -Wall. Starting with command lines, since directives have larger implications that need investigation Thanks,

On Jul 27, 2012, at 9:04 AM, Sebastien DELDON-GNB <sebastien.deldon at st.com> wrote: > Hi all, > > Does llc –march=thumb –mcpu=cortex-a9 enable generation of thumb2 code for armv7 ? That's how I usually do it. Somewhere in the target description we associate a9 with -mattr=+thumb2. There are plenty of other ways to get the same result, and it's all very confusing and

On Thu, 20 Apr 2006, Simon Burton wrote: >>> From what I remember, this is a bug in debian libc: >> some floating point flags are set incorrectly causing SIGFPE. >> Can't find the bug report ATM. > > Oh, it just showed up on numpy-discussion: > http://sources.redhat.com/bugzilla/show_bug.cgi?id=10 > > """ > #include <fenv.h> > void

Hi Manoj, Not too late at all, we have not got to that point of the work yet. Are there examples of this kind of build setup that are available publicly? I think I understand the problem but it'd help to see one in action. To see if there are any other Arm extensions that are already being added like this and whether those systems support GCC and how. Thanks, David Spickett.

Hi Moritz, On 26 September 2017 at 09:09, Moritz Angermann via llvm-dev <llvm-dev at lists.llvm.org> wrote: > I’ve run into a case where `llc -mattr=+soft-float` for > "armv7-unknown-linux-androideabi” segfaults, while > `llc -float-abi=soft` does not. Similarly if the > "target-features"="+soft-float” metadata is embedded, > llc segfaults. The float-abi

On Wed, 19 Apr 2006 18:21:32 -0500 (CDT) Chris Lattner <sabre at nondot.org> wrote: > > > I don't see what this has to do with anything, but... Me neither. > > > Is there a way I can disable SSE instruction generation in LLVM ? > > Yes. Pass -mattr=-sse1,-sse2,-sse3 to lli or llc. Right, that fixed it. BTW: from the --help:

Hi all, On following code when I use llc targeting ARM Cortex-A9 as follows, if vmlx-forwarding is turned off then 'vmla' instructions are generated. It seems that -mcpu=cortex-a9 enables it by default and thus less 'vmla' instructions are generated. On this specific example it doesn't make any difference in term of performance, but on a more complex example disabling

Hi Manoj, I tried a few other options myself: * function 'target' attribute - the list of extensions this supports isn't complete and it doesn't enable the ACLE macros needed for intrinsics * manually defining ACLE macros - this allows intrinsics and is additive but assumes that you're not relying on codegen to emit instructions. I don't think it helps the bug linked

Hi, Below is a document detailing changes we'd like to make to Clang/LLVM to improve the usability of the target options for ARM and AArch64. To keep things simple the proposed changes are listed at the start and you can find the supporting examples at the end of the document. I look forward to your feedback. Thanks, David Spickett. RFC New Clang target feature selection options for

On Thu, 2013-01-31 at 10:17 -0600, Bill Schmidt wrote: > > On Thu, 2013-01-31 at 09:42 -0600, Hal Finkel wrote: > > ----- Original Message ----- > > > From: "Bill Schmidt" <wschmidt at linux.vnet.ibm.com> > > > To: llvmdev at cs.uiuc.edu > > > Sent: Thursday, January 31, 2013 9:26:15 AM > > > Subject: [LLVMdev] Getting command line

Hi Anitha, Thanks for your answer but -mcpu=cortex-a9 -mattr=+vfp4 doesn' t enable fused mac generation for me. I would like just to understand why -mtriple=armv7-eabi enables it while -mcpu=cortex-a9 seems to disable it ? Seb > -----Original Message----- > From: Anitha Boyapati [mailto:anitha.boyapati at gmail.com] > Sent: Thursday, November 08, 2012 10:22 AM > To: Sebastien

This is a bit premature to be considered a code review, but given how unfamiliar I am with SelectionDAG (& that I'm seeing somewhat more 'interesting' results compared to my change to FastISel) I wanted to get a bit of feedback to see if I was on the right track or had missed any obvious cases. I've attached my patch in progress (including a modification to the existing test

----- Original Message ----- > From: "Bill Schmidt" <wschmidt at linux.vnet.ibm.com> > To: llvmdev at cs.uiuc.edu > Sent: Thursday, January 31, 2013 9:26:15 AM > Subject: [LLVMdev] Getting command line options to affect subtarget features > > The problem I'm trying to solve: Invoking clang on PowerPC with > -fno-altivec has no effect. > > From what

AFAIK A9 doesn't have VFPv4 or AdvSIMDv2, so it doesn't have VFMA. I don't know what LLVM does, but it shouldn't emit VFMA when you target A9. VMLA isn't a fused multiply-add, it's a multiply followed by an add and has different latency as well as precision. On Thu, Nov 8, 2012 at 4:57 AM, Sebastien DELDON-GNB < sebastien.deldon at st.com> wrote: > Hi Anitha,

The problem I'm trying to solve: Invoking clang on PowerPC with -fno-altivec has no effect. >From what I've been able to piece together, PPC.td specifies various CPUs and the processor features available on each. So for example we have: def FeatureAltivec : SubtargetFeature<"altivec","HasAltivec", "true",

On Thu, 2013-01-31 at 11:29 -0600, Bill Schmidt wrote: > On Thu, 2013-01-31 at 11:23 -0600, Bill Schmidt wrote: > > On Thu, 2013-01-31 at 10:17 -0600, Bill Schmidt wrote: > > > > > > On Thu, 2013-01-31 at 09:42 -0600, Hal Finkel wrote: > > > > ----- Original Message ----- > > > > > From: "Bill Schmidt" <wschmidt at

On Thu, 2013-01-31 at 09:42 -0600, Hal Finkel wrote: > ----- Original Message ----- > > From: "Bill Schmidt" <wschmidt at linux.vnet.ibm.com> > > To: llvmdev at cs.uiuc.edu > > Sent: Thursday, January 31, 2013 9:26:15 AM > > Subject: [LLVMdev] Getting command line options to affect subtarget features > > > > The problem I'm trying to