similar to: [LLVMdev] [cfe-dev] Converting a clang -cc1 invocation into an llc invocation

Displaying 20 results from an estimated 6000 matches similar to: "[LLVMdev] [cfe-dev] Converting a clang -cc1 invocation into an llc invocation"

2010 May 13
0
[LLVMdev] Returning big vectors on ARM broke in rev 103411
I don't think this has ever worked. Evan On May 13, 2010, at 10:03 AM, Edmund Grimley-Evans wrote: > I think this test case demonstrates it: > > ; RUN: llc -march=thumb -mcpu=cortex-a8 -mtriple=thumbv7-eabi -float-abi=hard < %s | FileCheck %s > > define <4 x i64> @f_4_i64(<4 x i64> %a, <4 x i64> %b) nounwind { > ; CHECK: vadd.i64 > %y = add <4
2010 May 14
2
[LLVMdev] Returning big vectors on ARM broke in rev 103411
It used to. I just checked with r90370. deep On Thu, May 13, 2010 at 11:53 PM, Evan Cheng <evan.cheng at apple.com> wrote: > I don't think this has ever worked. > > Evan > > On May 13, 2010, at 10:03 AM, Edmund Grimley-Evans wrote: > >> I think this test case demonstrates it: >> >> ; RUN: llc -march=thumb -mcpu=cortex-a8 -mtriple=thumbv7-eabi
2010 May 14
0
[LLVMdev] Returning big vectors on ARM broke in rev 103411
Ok, please file a bug. Evan On May 13, 2010, at 6:23 PM, Sandeep Patel wrote: > It used to. I just checked with r90370. > > deep > > On Thu, May 13, 2010 at 11:53 PM, Evan Cheng <evan.cheng at apple.com> wrote: >> I don't think this has ever worked. >> >> Evan >> >> On May 13, 2010, at 10:03 AM, Edmund Grimley-Evans wrote: >>
2010 May 13
2
[LLVMdev] Returning big vectors on ARM broke in rev 103411
I think this test case demonstrates it: ; RUN: llc -march=thumb -mcpu=cortex-a8 -mtriple=thumbv7-eabi -float-abi=hard < %s | FileCheck %s define <4 x i64> @f_4_i64(<4 x i64> %a, <4 x i64> %b) nounwind { ; CHECK: vadd.i64 %y = add <4 x i64> %a, %b ret <4 x i64> %y } (I hope I got that right.) -- IMPORTANT NOTICE: The contents of this email and any
2016 Jul 04
2
Simple program fails to compile depending on target os
Thanks! I also found test/CodeGen/ARM/ghc-tcreturn-lowered.ll, which tests only for thumbv7-eabi, so, i tried a few more variations: [x] arm64-apple-ios [x] arm64-apple-ios7.0.0 [x] arm64-apple-darwin [x] armv7-apple [x] thumbv7-apple [x] thumbv7-apple-darwin [x] i386-apple-ios [x] i386-apple-darwin [f] thumbv7-apple-ios [f] thumbv7-apple-ios7.0.0 [f] armv7-apple-ios I’ve also just build a
2010 Jul 23
1
[LLVMdev] "Cannot call createPass on PassInfo without default ctor!"
While trying to add a pass to the ARM back end I'm getting quite a lot of this assertion failure: Pass.cpp:255: llvm::Pass* llvm::PassInfo::createPass() const: Assertion `NormalCtor && "Cannot call createPass on PassInfo without default ctor!"' failed. A simple way to get it is to add two lines to ARMTargetMachine.cpp: #include "llvm/Transforms/Scalar.h" and
2015 Nov 19
2
thumbv7 build errors "requires arm-mode"
After a recent upstream pull, my builds for ARM thumbv7 suddenly fail with messages like: error: instruction requires: arm-mode 21 uxtah r6, r0, r6 I use llc with -mtriple=thumbv7-unknown-unknown and llvm-mc with -triple=thumbv7-unknown-unkown. What's the right way to generate thumbv7 binaries? Thanks, -steve
2010 Sep 25
2
[LLVMdev] custom lowering with multiple results
Here's a concrete example of what I'm having problems with: trying to use LowerOperation to replace one node with two nodes. Imagine I have a new instruction "read_world" that sets the status flags according to some kind of global state. In order to generate this instruction I have a built-in function with the prototype "int __builtin_read_world(void)". I also have a
2010 Jan 25
0
[LLVMdev] ambiguity of .align
2010/1/25 Edmund Grimley Evans <Edmund.Grimley-Evans at arm.com>: > I just got this error message from the GNU assembler: > > Error: alignment too large: 15 assumed > > Which made me laugh at first. The corresponding input line was: > >        .align  16 > > Apparently what's going on here is that ".align 16" is ambiguous: on > some architectures
2010 Jan 26
0
[LLVMdev] ambiguity of .align
Assuming you're working with an ARM target, you may also hit a problem with the alignment option on the .comm directive. Attached is a first-cut patch for this latter problem. deep On Mon, Jan 25, 2010 at 5:42 PM, Edmund Grimley Evans <Edmund.Grimley-Evans at arm.com> wrote: > I just got this error message from the GNU assembler: > > Error: alignment too large: 15 assumed
2010 May 17
3
[LLVMdev] ARM EABI Exceptions
Hi, I was comparing the way LLVM generates the exception table and it looks a bit different from what GCC (arm-none-eabi-g++) generates. Maybe that's because clang is not generating ARM IR when I do: $ clang -c -emit-llvm -march=arm -mcpu=cortex-a8 -mtriple=arm-none-eabi exception.cpp -o exception.clang.bc clang: warning: argument unused during compilation: '-mcpu=cortex-a8' clang:
2010 Dec 14
0
[LLVMdev] Which is more compact, .bc or .ll.gz? And what might be even more compact?
On Tue, 14 Dec 2010 10:55:09 -0000 "Edmund Grimley-Evans" <Edmund.Grimley-Evans at arm.com> wrote: > According to the few tests I did, .ll.gz is more compact: > > 1.00 LLVM bitcode (.bc) > 0.80 Gzipped LLVM bitcode (.bc.gz) > 4.13 LLVM assembly (.ll) > 0.68 Gzipped LLVM assembly (.ll.gz) > > However, there's not much in it, considering that a
2012 Nov 12
1
[LLVMdev] RE : fmac generation for cortex-a9
Hi Renato, You're right it's VMLA/VMLS that are generated. Still don't understand what drives generation for Cortex-A9. I was using fmac for floating point MAC not for fused MAC. Than I realized that we spoke about fma instead of fmac. So back to the original problem why when using -mcpu=cortex-a9 VMLA/VMLS are not generated and when I use -mtriple=armv7-eabi they are ? Best
2010 Jul 19
0
[LLVMdev] How to visualise Clang optimisation phases
Having a look at clang's source, you can find in "lib/CodeGen/BackendUtil.cpp" the functions where clang builds the passes to emit code. The optimization passes used are there and you can simulate them via the "opt" utility, by running each pass one at a time. LLVM also declares standard module/function passes on include/llvm/Support/StandardPasses.h. Have a look and see
2012 Nov 09
0
[LLVMdev] fmac generation for cortex-a9
Hi Sebastien, ARMv7-M has VFMA and LLVM's "triple" is far from perfect. Wikipedia tells me NovaThor can also be A15, or STE could have cramped a VFPv4 in it? ;) Or possibly, your code never branches into the VFMA. Many things could be happening, but usually, VFMA shouldn't be generated for A9. A GCC bug, maybe? On 9 November 2012 16:51, Sebastien DELDON-GNB
2012 Nov 09
2
[LLVMdev] fmac generation for cortex-a9
Hi Bastien, Weird gcc is generating fma for my platform STEricsson Novathor with Linaro, code works. It also works when I use LLVM to generate fma (using llc -mtriple=armv7-eabi). Maybe someone from ARM can answer the question ? Seb From: JF Bastien [mailto:jfb at google.com] Sent: Friday, November 09, 2012 5:36 PM To: Sebastien DELDON-GNB Cc: Anitha Boyapati; llvmdev at cs.uiuc.edu Subject:
2012 Nov 09
0
[LLVMdev] fmac generation for cortex-a9
cat /proc/cpuinfo ? Are you sure it's generating VFMA and not VMLA? On Fri, Nov 9, 2012 at 9:35 AM, Sebastien DELDON-GNB < sebastien.deldon at st.com> wrote: > Hi Renato, > > It's definitively not A15. Can this be the case that NEON units for > cortex-A9 support it but isn't documented/recommended ? > And as mentioned before code is working ! > > Seb >
2012 Nov 08
2
[LLVMdev] fmac generation for cortex-a9
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
2012 Nov 09
0
[LLVMdev] fmac generation for cortex-a9
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,
2012 Nov 09
2
[LLVMdev] fmac generation for cortex-a9
Hi Renato, It's definitively not A15. Can this be the case that NEON units for cortex-A9 support it but isn't documented/recommended ? And as mentioned before code is working ! Seb > -----Original Message----- > From: rengolin at gmail.com [mailto:rengolin at gmail.com] On Behalf Of > Renato Golin > Sent: Friday, November 09, 2012 6:27 PM > To: Sebastien DELDON-GNB >