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

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

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 }

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

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

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

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

Chris, > FYI, I completely agree that we shouldn't remove the sparc target. However, it is currently unmaintained, and has some pretty glaring bugs. Is anyone interested in stepping up to maintain the target? > > -Chris We can not let it die and I volunteer to keep the Sparc alive! My SPARCstation pizzaboxes can be ready for action in a day or two. Pawel Wodnicki > On Oct

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,

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

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

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?

> I've seen the exact same in my version (mingw on win32), and the problem > was that the stack was misaligned when entering the function, so the temp > registers weren't at 16-byte boundries. That's a possibility. It's easy to check by printing the address of the variables. I know that gcc 3.3 had some alignment issues with _m128 that were supposed to be fixed in

Hello everyone, while working on a simple PE-Parser, using the llvm/Support/COFF.h Header, to validate if a given File is a PE-File and to read the Machine Field I was experiencing some troubles. It seemed the Fields were somehow misaligned and I could pinpoint the source of the misalignment to be the "NumberOfSections" field inside the "header"-struct (a.k.a.

> On Jan 14, 2016, at 4:49 PM, Richard Smith <richard at metafoo.co.uk> wrote: > On Thu, Jan 14, 2016 at 12:56 PM, John McCall via cfe-dev <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote: > C 6.3.2.3p7 (N1548) says: > A pointer to an object type may be converted to a pointer to a > different object type. If the resulting pointer is not