similar to: [LLVMdev] Patch: Compiling LLVM in Sparc

Displaying 20 results from an estimated 1200 matches similar to: "[LLVMdev] Patch: Compiling LLVM in Sparc"

2009 Aug 25
0
[LLVMdev] Patch: Compiling LLVM in Sparc
Hi Venkatraman, > The current version in SVN fails to compile in sparc machines since > gcc defines "sparc" as a macro in sparc machines that expands to 1 > (see below) but Triple.h defines "sparc" as a enum constant. > > $ cpp -dM /dev/null | grep sparc > #define sparc 1 > #define __sparc__ 1 > #define __sparc 1 > > The attached patch
2009 Aug 25
3
[LLVMdev] Patch: Compiling LLVM in Sparc
Instead of just upcasing them, can we add prefix ARCH_? --Venkatraman On Tue, Aug 25, 2009 at 2:36 AM, Eric Christopher<echristo at apple.com> wrote: > > On Aug 25, 2009, at 12:32 AM, Daniel Dunbar wrote: > >> Hi, >> >> I think I should rename the constants to be a little less likely to >> collide. I think just upcasing them might be good enough? > >
2009 Aug 25
0
[LLVMdev] Patch: Compiling LLVM in Sparc
I would prefer not to; they already live in a protected namespace, so there is no need to mangle them except to protect them from exuberant preprocessor defines, and this would be slightly out of style with other public uses of enumerations in LLVM. - Daniel On Tue, Aug 25, 2009 at 7:49 AM, Venkatraman Govindaraju<venkatra at cs.wisc.edu> wrote: > Instead of just upcasing them, can we
2009 Aug 25
4
[LLVMdev] Patch: Compiling LLVM in Sparc
Hi, I think I should rename the constants to be a little less likely to collide. I think just upcasing them might be good enough? - Daniel On Tue, Aug 25, 2009 at 12:20 AM, Duncan Sands<baldrick at free.fr> wrote: > Hi Venkatraman, > >>  The current version in SVN fails to compile in sparc machines since >> gcc defines "sparc" as a macro in sparc machines that
2009 Aug 25
0
[LLVMdev] Patch: Compiling LLVM in Sparc
On Aug 25, 2009, at 12:32 AM, Daniel Dunbar wrote: > Hi, > > I think I should rename the constants to be a little less likely to > collide. I think just upcasing them might be good enough? It should, this is the pattern generally emitted by all of the backends. >>> >>> $ cpp -dM /dev/null | grep sparc >>> #define sparc 1 >>> #define __sparc__ 1
2012 Nov 22
2
[LLVMdev] Code ownership - Target/Sparc
I would like to take ownership of Target/Sparc, if no one objects. Thanks, Venkatraman -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121121/53828f4b/attachment.html>
2011 Jan 07
2
[LLVMdev] Unreachable executed with fast Regalloc and Sparc backend
Hello, When I run LLC with option "-O0 -march=sparc" on following testcase, fast register allocator crashes with "UNREACHABLE executed" error. LLC generates code successfully with other standard register allocators available. $ cat call.ll define void @test() nounwind { entry: %0 = tail call i32 (...)* @foo() nounwind tail call void (...)* @bar() nounwind ret void }
2014 Feb 02
2
[LLVMdev] LLVM/Clang on Sparc64
On Sun, Feb 2, 2014 at 11:50 AM, Anton Korobeynikov <anton at korobeynikov.info> wrote: > That's really cool! Should we add note to Release Notes? Definitely. I will add a note mentioning about this in ReleaseNotes.rst. > > On Sun, Feb 2, 2014 at 8:05 PM, Venkatraman Govindaraju > <venkatra at cs.wisc.edu> wrote: >> Thanks to Jakob's work on Sparcv9 ABI in
2014 Feb 02
3
[LLVMdev] LLVM/Clang on Sparc64
Thanks to Jakob's work on Sparcv9 ABI in Clang and recent changes to Sparc code generator, I am happy to announce that Clang can self host itself on Linux/Sparc64 and on FreeBSD/Sparc64. However, it still fails on a few unit tests and nightly tests, primarily due to misaligned memory accesses in the code (See bugs 18482, 18500, 18502, 18536, 18693). Unlike other architectures, misaligned
2011 Oct 26
2
[LLVMdev] is anyone using the sparc backend?
On Wed, Oct 26, 2011 at 1:59 AM, Chris Lattner <clattner at apple.com> wrote: > > Fantastic.  A great place to start would be to investigate / screen various sparc related bugs in bugzilla to see if they are still relevant and present: > http://llvm.org/bugs/buglist.cgi?quicksearch=sparc > > This bug looks pretty fatal if it is actually real: >
2011 Sep 16
2
[LLVMdev] problem with sgt's on Sparc machine
Hello, What is your LLVM version? Also, can you attach the assembly generated? Thanks, Venkatraman On Thu, Sep 15, 2011 at 5:20 PM, Bruno Cardoso Lopes <bruno.cardoso at gmail.com> wrote: > Hi, > > On Thu, Sep 15, 2011 at 3:15 PM, Christine Cheng <clcheng at stanford.edu> wrote: >> Hi guys, >> >> Thanks for the input. However, it seems that the code
2011 Sep 16
2
[LLVMdev] problem with sgt's on Sparc machine
Hi Christine, > I am using LLVM 2.8 and llvm-gcc 4.2. Could you please try svn top-of-tree? Clang is also a better choice here. > The assembly files are attached. In the assembly file, the erroneous result > is associated with 'subcc', while the correct ones are associated with 'or'. -- Bruno Cardoso Lopes http://www.brunocardoso.cc
2011 Sep 16
0
[LLVMdev] problem with sgt's on Sparc machine
I can't reproduce this problem with the recent svn trunk. LLVM 2.9 has lots of fixes for Sparc back-end. So, please at least try with LLVM-2.9. Thanks, On Fri, Sep 16, 2011 at 6:30 PM, Bruno Cardoso Lopes <bruno.cardoso at gmail.com> wrote: > Hi Christine, > >> I am using LLVM 2.8 and llvm-gcc 4.2. > > Could you please try svn top-of-tree? Clang is also a better
2011 Jan 08
0
[LLVMdev] Unreachable executed with fast Regalloc and Sparc backend
On Jan 7, 2011, at 2:36 PM, Venkatraman Govindaraju wrote: > When I run LLC with option "-O0 -march=sparc" on following testcase, > fast register allocator crashes with "UNREACHABLE executed" error. LLC > generates code successfully with other standard register allocators > available. I haven't investigated the Sparc backend specifically but... My guess is
2011 Sep 16
0
[LLVMdev] problem with sgt's on Sparc machine
Hi Venkatraman, I am using LLVM 2.8 and llvm-gcc 4.2. The assembly files are attached. In the assembly file, the erroneous result is associated with 'subcc', while the correct ones are associated with 'or'. Thanks a lot! Christine On Fri, Sep 16, 2011 at 2:29 PM, Venkatraman Govindaraju < venkatra at cs.wisc.edu> wrote: > Hello, > > What is your LLVM version?
2011 Jan 20
2
[LLVMdev] Modifying the patterns/ instruction selection phase in LLVM 2.7
On 1/20/11 12:27 PM, Venkatraman Govindaraju wrote: Just out of curiosity, have either of you considered writing an LLVM transform that simply replaces these call instructions with inline assembly code that does what you want? If that works, it seems much simpler than modifying/enhancing the code generator. -- John T. > I have similar requirements for my project. This is what I do. >
2011 Jan 20
0
[LLVMdev] Modifying the patterns/ instruction selection phase in LLVM 2.7
For my case, I can't replace these call instructions with inline assembly code because I need to encode the registers into the "number". For instance, if the call instruction is %result = call i32 @foo(i32 %a) and the result is assigned to register %l0 and the variable "a" to register %l1, then I encode all foo, %l0 and %l1 and generate a sethi instruction. thanks,
2011 Jan 20
0
[LLVMdev] Modifying the patterns/ instruction selection phase in LLVM 2.7
I have similar requirements for my project. This is what I do. 1. Add a new intrinsic function to LLVM that corresponds to "functions with particular type of function names". The steps to create intrinsic function is documented in http://llvm.org/docs/ExtendingLLVM.html#intrinsic. 2. Create a lowering pass that lowers "functions with particular type" ( eg. p0, p1) to
2011 Jan 19
2
[LLVMdev] Modifying the patterns/ instruction selection phase in LLVM 2.7
Hello all, I am trying to modify the Sparc backend to do something for my team's project, to do the following. Whenever the backend encounters a call to one particular type of function names (functions like p0(), p1()..etc), I want the backend to generate a "sethi %g0, <number>", and NOT a "call p0, call p1..." instruction. However, the backend should work as usual
2014 Jan 10
8
[LLVMdev] All backends now use the MC asm printer
In r198030 the last in tree backend was converted to use MCInst for printing assembly. I removed support for the old printer in r198959. Out of tree targets have to lower MachineInstr to MCInst to use the new printer. Cheers, Rafael