similar to: [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

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? > >

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

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

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

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>

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 }

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

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

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: >

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

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

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

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

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?

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. >

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,

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

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

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