similar to: [LLVMdev] AVR back end

Hello. I was wondering if it is possible to implement placing RO variables within progmem sections. For now it is possible to just use [[gnu::progmem]] and read variables using assembly. My proposal is to: Use those variables as any other, without creating assembly. While reading them, compiler has all necessary knowledge where the variable is and can generate assembly Possible future

I'm attempting to implement codegen support for the AVR ST/LD <http://www.atmel.com/webdoc/avrassembler/avrassembler.wb_ST.html> family of instructions. The binary encoding is not particularly consistent -- take a look at this table of variants of LD, along with their machine code representation: # load 8 bits from pointer register X into general purpose Rd ld Rd, X `1001 000d dddd

Hi All, For quite some time there's been a side project for developing an AVR back end for LLVM: http://sourceforge.net/projects/avr-llvm/ What is required from us to be able to add this work to the LLVM repo? And when do you think would be a good time for us to do that? If this is located somewhere in the docs and I've missed it, pointers would certainly be appreciated. Thanks, Eric

On 11 March 2013 16:13, Anitha B Gollamudi <anitha.boyapati at gmail.com> wrote: > On 11 March 2013 10:06, Anitha B Gollamudi <anitha.boyapati at gmail.com> wrote: >> On 23 January 2013 00:20, Craig Topper <craig.topper at gmail.com> wrote: >>> >>> Are you still having issues with FMA4? I wonder if PR15040 is related. A >>> fix was just

Can you send the binaries compiled with and without the integrated assembler. Maybe I can figure out the encoding problem. I've been unsuccessful figuring it out myself so far. On Tue, Mar 12, 2013 at 12:34 AM, Anitha B Gollamudi < anitha.boyapati at gmail.com> wrote: > On 12 March 2013 09:51, Craig Topper <craig.topper at gmail.com> wrote: > > I'm still slightly

On 11 March 2013 10:06, Anitha B Gollamudi <anitha.boyapati at gmail.com> wrote: > On 23 January 2013 00:20, Craig Topper <craig.topper at gmail.com> wrote: >> >> Are you still having issues with FMA4? I wonder if PR15040 is related. A >> fix was just committed. Unfortunately r173176 does not fix this. I have updated the trunk and ran...Miscompare still persists.

Looks like recent changes to Attributes.h broke the dragonegg build. I am building with latest clang and llvm trunk. clang version 3.2 (trunk 165928) (llvm/trunk 165925) Target: x86_64-unknown-linux-gnu Thread model: posix >>>>> Compiling TypeConversion.cpp /local/home/anitha/dragonegg/src/TypeConversion.cpp: In function âllvm::FunctionType* ConvertArgListToFnType(tree,

On 12 March 2013 09:51, Craig Topper <craig.topper at gmail.com> wrote: > I'm still slightly confused. Is the error now fixed or is there still a bug > in LLVM's integrated assembler? > The error is not fixed yet (even with fix mentioned in PR15040 http://llvm.org/bugs/show_bug.cgi?id=15040#c4) With the updated trunk, clang still gives an error when FMA4 is enabled but

I'm still slightly confused. Is the error now fixed or is there still a bug in LLVM's integrated assembler? On Mon, Mar 11, 2013 at 4:49 AM, Anitha B Gollamudi < anitha.boyapati at gmail.com> wrote: > On 11 March 2013 17:00, Duncan Sands <baldrick at free.fr> wrote: > > Hi Anitha, > > > > > >> Ah, I am taking back my above words w.r.t encoding.

On 7 April 2013 14:54, Sam Parker <S.Parker3 at lboro.ac.uk> wrote: > Hi Anitha, > > memri is just describing that the address contains two components, an > immediate and a register, and how to handle them in the instruction printer. > The STWU expects a memri operand, and that is what is passed from the Pat. > My confusion is how operands of STWU from "Pat

On 23 January 2013 00:20, Craig Topper <craig.topper at gmail.com> wrote: > > Are you still having issues with FMA4? I wonder if PR15040 is related. A > fix was just committed. It seems to be so! I will look into it immediately. Apologies for the late e-mail. I ran out of time devoted for this PR and moved on. Coincidentally, only today I came back to this PR for further

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:

You've unfortunately chosen a complex example. Your second question is needs be answered first. null_frag causes the pattern to be dropped. Now having covered that the reason the operands are in the order they are is because the only instruction that doesn't use null_frag is this one defm r213 : fma3s_rm<opc213, !strconcat(OpStr, !strconcat("213", PackTy)),

On 6 November 2012 14:52, Duncan Sands <baldrick at free.fr> wrote: > Hi Anitha, > > > On 06/11/12 10:19, Anitha Boyapati wrote: > >> Hi Duncan >> I am facing a build error about __builtin_iceil >> > > it's surely just that dragonegg doesn't have any support for this builtin. > ok. Just verified that Target.cpp and x86_builtins do not have

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,

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

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

Hi Anitha, On 06/11/12 10:19, Anitha Boyapati wrote: > Hi Duncan > I am facing a build error about __builtin_iceil it's surely just that dragonegg doesn't have any support for this builtin. Please open a bug report with a minimal test case. Ciao, Duncan. when compiled > with dragonegg using -ffast-math option. My dragonegg is built with gcc-4.7.0 > (I am compiling namd

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

Hi Anitha, > it's surely just that dragonegg doesn't have any support for this builtin. > > ok. Just verified that Target.cpp and x86_builtins do not have iceil support. > I have this tricky situation - I use dragonegg generated LLVM IR as input to > clang for some analysis (well it is clang++ actually). Understably,clang cribs > looking at __builtin_iceil. Any idea