search for: targetaddress

...in registers!"); - Chain = DAG.getCopyToReg(Chain, VA.getLocReg(), Op.getOperand (i*2+1), - Flag); - Flag = Chain.getValue(1); - } + if (IsLastCallTailCall) { + IsLastCallTailCall = false; + SDOperand TailCall = GetTailCall(Op); + SDOperand TargetAddress = TailCall.getOperand(1); + SDOperand StackAdjustment = TailCall.getOperand(2); + assert ( ((TargetAddress.getOpcode() == ISD::Register && + cast<RegisterSDNode>(TargetAddress)->getReg() == X86::ECX) || + TargetAddress.getOpcode() == ISD::TargetEx...

Hi Evan, first off thanks to you and Chris for taking time. On 6 Sep 2007, at 00:57, Evan Cheng wrote: > We'd like to see tail call optimization to be similar to the target > independent lowering of ISD::CALL nodes. These are auto-generated > from ???CallingConv.td files. Some target specific details such as > function address register (ECX in your example) should be coded in

...o facilitate this already been added? Would it be possible to merge this in? diff --git a/CompileOnDemandLayer.h b/CompileOnDemandLayer.h index bd192b8..4aa3362 100644 --- a/CompileOnDemandLayer.h +++ b/CompileOnDemandLayer.h @@ -429,6 +429,28 @@ private: return CalledAddr; } +public: + TargetAddress updatePointer(std::string FuncName, TargetAddress FnBodyAddr) { + //Find out which logical dylib contains our symbol + auto LDI = LogicalDylibs.begin(); + for (auto LDE = LogicalDylibs.end(); LDI != LDE; ++LDI) { + if (auto LMResources = LDI->getLogicalModuleResourcesForSymbol(Fu...

...G.getCopyToReg(Chain, VA.getLocReg(), Op.getOperand > (i*2+1), > - Flag); > - Flag = Chain.getValue(1); > - } > + if (IsLastCallTailCall) { > + IsLastCallTailCall = false; > + SDOperand TailCall = GetTailCall(Op); > + SDOperand TargetAddress = TailCall.getOperand(1); > + SDOperand StackAdjustment = TailCall.getOperand(2); > + assert ( ((TargetAddress.getOpcode() == ISD::Register && > + cast<RegisterSDNode>(TargetAddress)->getReg() == > X86::ECX) || > + TargetAddress.getOp...

...ssible to merge this in? > > diff --git a/CompileOnDemandLayer.h b/CompileOnDemandLayer.h > index bd192b8..4aa3362 100644 > --- a/CompileOnDemandLayer.h > +++ b/CompileOnDemandLayer.h > @@ -429,6 +429,28 @@ private: > return CalledAddr; > } > > +public: > + TargetAddress updatePointer(std::string FuncName, TargetAddress > FnBodyAddr) { > + //Find out which logical dylib contains our symbol > + auto LDI = LogicalDylibs.begin(); > + for (auto LDE = LogicalDylibs.end(); LDI != LDE; ++LDI) { > + if (auto LMResources = > LDI->getLogi...

...iff --git a/CompileOnDemandLayer.h b/CompileOnDemandLayer.h >> index bd192b8..4aa3362 100644 >> --- a/CompileOnDemandLayer.h >> +++ b/CompileOnDemandLayer.h >> @@ -429,6 +429,28 @@ private: >> return CalledAddr; >> } >> >> +public: >> + TargetAddress updatePointer(std::string FuncName, TargetAddress >> FnBodyAddr) { >> + //Find out which logical dylib contains our symbol >> + auto LDI = LogicalDylibs.begin(); >> + for (auto LDE = LogicalDylibs.end(); LDI != LDE; ++LDI) { >> + if (auto LMResources =...

.../CompileOnDemandLayer.h >>> index bd192b8..4aa3362 100644 >>> --- a/CompileOnDemandLayer.h >>> +++ b/CompileOnDemandLayer.h >>> @@ -429,6 +429,28 @@ private: >>> return CalledAddr; >>> } >>> >>> +public: >>> + TargetAddress updatePointer(std::string FuncName, TargetAddress >>> FnBodyAddr) { >>> + //Find out which logical dylib contains our symbol >>> + auto LDI = LogicalDylibs.begin(); >>> + for (auto LDE = LogicalDylibs.end(); LDI != LDE; ++LDI) { >>> + if...

...> index bd192b8..4aa3362 100644 >>>> --- a/CompileOnDemandLayer.h >>>> +++ b/CompileOnDemandLayer.h >>>> @@ -429,6 +429,28 @@ private: >>>> return CalledAddr; >>>> } >>>> >>>> +public: >>>> + TargetAddress updatePointer(std::string FuncName, TargetAddress >>>> FnBodyAddr) { >>>> + //Find out which logical dylib contains our symbol >>>> + auto LDI = LogicalDylibs.begin(); >>>> + for (auto LDE = LogicalDylibs.end(); LDI != LDE; ++LDI) { >>&...

Hi Lang, Thanks for the reply. Responses below. As far as I know nobody is actively working on MCJIT any more. I've been > working on the next generation of LLVM JIT APIs (ORC - see > include/llvm/ExecutionEngine/Orc) for a while now, but they don't have > functionality for running arbitrary functions yet. > Thanks for the pointer to ORC -- it looks like the runFunction

...bug; works like a charm! I’ve been unable to reproduce the 32 bit relocation on 64 bit code (I’ll let you know if I do). However, I’m still having issues with resolving the 64 bit symbol relocations. In case it’s relevant, the specific symbol my program is tripping up on is IID_IOleObject, where TargetAddress is dereferenced inside of the COFF::IMAGE_REL_AMD64_ADDR64 case of resolveRelocation inside RuntimeDyldCOFFx86_64. I took a look at the link provided earlier and noticed a few things... - LLILC provides a resolver that simply returns UINT64_MAX for any given symbol, which the comment explains indi...

Hi David, This is really cool. I'd love to get this in-tree. There are two ways we could go about this: (1) Make the OrcArchitecture interface ABI-aware so that it can choose the right resolver code, or (2) Replace the OrcArchitecture classes with OrcABI classes. I.e. We'd just a rename OrcX86_64 -> Orc_X86_64_SysV (and rename I386 & AArch64 similarly) , then we add your code as

That's great news, thanks! If I can be of any help, let me know. :) I'll see if I can reduce the example for the relocation issue whilst you're at it. Regards, Joshua -- Joshua Gerrard JUCE Software Developer *ROLI’s **award-winning* <http://www.telegraph.co.uk/luxury/design/31520/the-seaboard-grand-piano-wins-designs-of-the-year-2014-award.html>* Seaboard GRAND, celebrated