similar to: [LLVMdev] Instruction does not dominate all uses

Hi all, I'm getting a weird error if I run llc on the attached module. Did I do something wrong (llc says the module is broken, also attached) or is this a bug? Cheers, Gary -- http://gbenson.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: test.bc Type: application/octet-stream Size: 2060 bytes Desc: not available URL:

Hi all, When you genetate code on PowerPC you need to explicitly invalidate the instruction cache to force the processor to reread it. In LLVM there is code to do this for function stubs on Macintosh, but not for other platforms and not for JITted code generally. The attached patch adds support for GNU platforms, but I can't figure out a nice way to call it for all generated code. Can

No, I don't. Cheers, Gary Dale Johannesen wrote: > This looks OK to check in, do you have write access? > > On Aug 21, 2008, at 6:38 AMPDT, Gary Benson wrote: > > >Dale Johannesen wrote: > >>On Aug 19, 2008, at 7:18 AMPDT, Gary Benson wrote: > >>>I'm trying to implement llvm.memory.barrier on PowerPC. I've > >>>modelled my patch

Hi Gary, Gary Benson wrote: > Hi all, > > When you genetate code on PowerPC you need to explicitly invalidate > the instruction cache to force the processor to reread it. In LLVM > there is code to do this for function stubs on Macintosh, but not > for other platforms and not for JITted code generally. > > Did you run into errors when not invalidating the cache? vmkit

Look for createVirtualRegister. These are examples in PPCISelLowering.cpp. Evan On Jul 8, 2008, at 8:24 AM, Gary Benson wrote: > Hi Evan, > > Evan Cheng wrote: >> The patch looks great. But I do have one comment: >> >> +let usesCustomDAGSchedInserter = 1 in { >> + let Uses = [CR0] in { >> + let Uses = [R0] in >> + def ATOMIC_LOAD_ADD_I32 :

Hi all, I want to implement llvm.memory.barrier on PowerPC. The implementation would be the single instruction "sync", but currently it's defined with: setOperationAction(ISD::MEMBARRIER, MVT::Other, Expand) in lib/Target/PowerPC/PPCISelLowering.cpp, which causes it to be a noop. I replaced the "Expand" with "Legal" in the hope I'd get an error message

Hi Evan, Evan Cheng wrote: > The patch looks great. But I do have one comment: > > +let usesCustomDAGSchedInserter = 1 in { > + let Uses = [CR0] in { > + let Uses = [R0] in > + def ATOMIC_LOAD_ADD_I32 : Pseudo< > > The "let Uses = [R0]" is not needed. The pseudo instruction will be > expanded like this later: > > + BuildMI(BB,

Committed. Thanks! Evan On Jul 11, 2008, at 1:07 PM, Gary Benson wrote: > Hi Evan, > > Evan Cheng wrote: >> This does not patch cleanly for me (PPCISelLowering.cpp). Can you >> prepare a updated patch? > > This should work, though I won't have access to my test box now until > next Thursday so no guarantees :) > > Cheers, > Gary > > -- >

Hi Gary, > The attached patch generalizes it (aKor helped me out). I don't know > if Intel needs some kind of cache invalidation too but if it does it > could use the same hooks. I've applied patch but with some changes in order not to break non-PPC builds. Please check whether it will work for you or not. I was pretty impressed, that there is no built-in defines for your

This looks OK to check in, do you have write access? On Aug 21, 2008, at 6:38 AMPDT, Gary Benson wrote: > Dale Johannesen wrote: >> On Aug 19, 2008, at 7:18 AMPDT, Gary Benson wrote: >>> I'm trying to implement llvm.memory.barrier on PowerPC. I've >>> modelled my patch (attached) on the implementation in X86, but >>> when I try and compile my test

Hi all, When I've been disassembling JIT-compiled functions I've noticed they all have the same three random instructions after them: bns- cr5,0xd04bbfe8 stfs f10,-16404(r3) stfs f10,-16404(r3) Is this meant to be there? Cheers, Gary -- http://gbenson.net/

Dale Johannesen wrote: > On Aug 19, 2008, at 7:18 AMPDT, Gary Benson wrote: > > I'm trying to implement llvm.memory.barrier on PowerPC. I've > > modelled my patch (attached) on the implementation in X86, but > > when I try and compile my test file (also attached) with llc I > > get the error "Cannot yet select: 0x10fa4ad0: ch = MemBarrier > >

Thanks. One thing though, who's Chris? Cheers, Gary Dale Johannesen wrote: > OK, I've checked it in for you, thanks. Please do contact Chris > about write access. > > On Aug 22, 2008, at 12:38 AMPDT, Gary Benson wrote: > > No, I don't. > > > > Cheers, > > Gary > > > > Dale Johannesen wrote: > > > This looks OK to check

OK, I've checked it in for you, thanks. Please do contact Chris about write access. On Aug 22, 2008, at 12:38 AMPDT, Gary Benson wrote: > No, I don't. > > Cheers, > Gary > > Dale Johannesen wrote: >> This looks OK to check in, do you have write access? >> >> On Aug 21, 2008, at 6:38 AMPDT, Gary Benson wrote: >> >>> Dale Johannesen

Hi all, As I understand it, LLVM's JIT memory manager works by allocating a 16Mb block of memory and generating native code into it. Once that block is exhausted no more functions can be JIT compiled. I'm trying to figure out ways to work around this limitation. One idea I had was to use that 16Mb block as a scratch area for generating code. Once a method has been compiled (and

On Thu, Aug 20, 2009 at 6:42 AM, Gary Benson<gbenson at redhat.com> wrote: > Hi all, > > As I understand it, LLVM's JIT memory manager works by allocating a > 16Mb block of memory and generating native code into it.  Once that > block is exhausted no more functions can be JIT compiled.  I'm trying > to figure out ways to work around this limitation. Nope, I

It could be stubs, data in text sections. Jump tables, constant pools, etc.? Are they ever executed? Evan On Jul 3, 2008, at 2:15 AM, Gary Benson wrote: > Hi all, > > When I've been disassembling JIT-compiled functions I've noticed they > all have the same three random instructions after them: > > bns- cr5,0xd04bbfe8 > stfs f10,-16404(r3) > stfs

Looks good. + unsigned temp; + if (is64bit) + temp = RegInfo.createVirtualRegister(&PPC::GPRCRegClass); + else + temp = RegInfo.createVirtualRegister(&PPC::G8RCRegClass); How about? const TargetRegisterClass *RC = is64Bit ? &PPC:GPRCRegClass : &PPC:G8RCRegClass; unsigned TmpReg = RegInfo.createVirtualRegister(RC); Evan On Jul 9, 2008, at 9:16 AM, Gary

Hi, I noticed that if you create a switch with multiple cases going to the same destination, then if that destination contains phis you need to add the incoming value an equivalent number of times. The attached code seems wrong, but it compiles as correct, and removing the duplicated incoming node causes an error. Is this expected? Cheers, Gary -- http://gbenson.net/ -------------- next part

On Mon, 16 Jun 2008, Gary Benson wrote: > When you genetate code on PowerPC you need to explicitly invalidate > the instruction cache to force the processor to reread it. In LLVM > there is code to do this for function stubs on Macintosh, but not > for other platforms and not for JITted code generally. Applied, thanks!