similar to: [LLVMdev] Code ownership - Target/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? > >

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

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

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

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 }

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

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

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

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

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?

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

Hi LLVM developers, As one of the maintainers of AVR target, I want to update WritingAnLLVMBackend document to be familiar with the development of backend, because: 1. The structure of LLVMTargetMachine https://github.com/llvm-mirror/llvm/blob/master/docs/WritingAnLLVMBackend.rst#target-machine has been changed a lot! 2. LLVMInitializeSparcTargetInfo

Hello, 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 fixes this problem by renaming sparc to sparc_. Thanks,

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

> In addition to thanking you for providing the info, I'm writing in the > hopes that there is some documentation that exists or that someone is > willing to add to http://llvm.org/docs/ExceptionHandling.html (or a more > appropriate place with a link there) that would cover the back end > (target-specific) aspects of EH. Perhaps just a quick description of what a > target

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

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