similar to: [LLVMdev] IR from Callee Dag Node

On 04/28/2013 09:49 PM, reed kotler wrote: > Is there a way to find the IR that corresponds to a callee DAG node? > > In other words to get the function definition, attributes, etc.? > > Tia. > > Reed It looks like you can do this by: 1) getParent will return the Module that some global value is in 2) in Module, getFunction will return the function

I am again calling for help from LLVM developers ;) For my DSP backend, at the lowering stage and also at the AsmPrinter stage, I need to know if a GlobalAddress is a code or a data address. So I tried at the lowering stage to use: GlobalAddressSDNode *GSDN = cast<GlobalAddressSDNode>(Op); const GlobalValue *GV = GSDN->getGlobal(); GV->hasSection() and GV->getSection() But the

I reply to myself... I didn't go in the right direction in my previous email. There is an easy way to tell if a GlobalValue corresponds to data or code: const GlobalValue *GV; if(Function::classof(GV)) ... // process the global value as a function else ... // process the global value as data Damien On Fri, Mar 18, 2011 at 3:16 PM, Damien Vincent <damien.llvm at

On 3/21/11 2:00 PM, Damien Vincent wrote: > I reply to myself... I didn't go in the right direction in my previous > email. > > There is an easy way to tell if a GlobalValue corresponds to data or code: > const GlobalValue *GV; > if(Function::classof(GV)) > ... // process the global value as a function > else > ... // process the global value as data > >

Hi, I am trying to write a LowerCALL() function for my (custom) target ISA. All I need to do is map a CALL instruction directly onto an SDNode that takes an equal number of arguments (very much alike intrinsics, except that these are custom to my target.) I do not need to implement any call sequences, stack frames etc. I get the following assertion failure: llc: LegalizeDAG.cpp:834:

Hi, attached is a small testcase I did. It builds two LLVM functions which both call two native functions get5 and get6. The native functions are in the exe and in the dll. On OS X it works like a charm. On Linux none of the two functions can be called. Maybe someone can try them or have a look at it to see if there is something obviously wrong greetings, Jan -------------- next part

Dear Community, To improve current interprocedural register allocation (IPRA) , we have planned to set callee saved registers to none for local functions, currently I am doing it in following way: if (F->hasLocalLinkage() && !F->hasAddressTaken()) { DEBUG(dbgs() << "Function has LocalLinkage \n"); F->setCallingConv(CallingConv::GHC); } but we think threre

Hi Jan, If I recall correctly, in Linux you get the message: PPCJITInfo.cpp:382: failed assertion `ResultPtr >= -(1 << 23) && ResultPtr < (1 << 23) && "Relocation out of range!"' Right? But on OS X you don't have this messsage? Here's a temporary fix until I find time to investigate on this: In function PPCISelLowering::LowerCALL,

Hello, I am learning to write a new backend for LLVM and have a few simple questions. 1) What are the differences between 'constant' and 'targetconstant', 'globaladdress' and 'targetglobaladdress'? It is not clear from the document when and which should be used. 2) On the processor I am working on, there is a 'move reg, mem_addr' instruction. When I try

Hi Nickhil, The Legalizer expects lower'd call is the node that produce the same number of values as the non-lowered node. That's what the assertion is checking. Take a look at the LowerCall routine for any other targets. You will see that in the non-void function case, it returns a MERGE_VALUES, i.e. all the results merged along with the chain. Cheers, Evan On Nov 15, 2006, at

Every GlobalAddress has a GlobalValue, Every GlobalValue is a PointerType, Every PointerType has an AddressSpace. So is it ok to add a method getAddressSpace in GlobalAddressSDNode class itself? Currently we have to do GSDN->getGlobal()->getType()->getAddressSpace(). - Sanjiv

Hey Evan, At the point of the instructions you suggested I step through, X86ISelLowering has this state: - this 0x00000000005fe728 {VarArgsFrameIndex=-842150451 RegSaveFrameIndex=-842150451 VarArgsGPOffset=3452816845 ...} llvm::X86TargetLowering * const + llvm::TargetLowering {TM={...} TD=0x00000000008edac0

On 20/04/2009, at 07.35, Peter Bacon wrote: > Hello, I am learning to write a new backend for LLVM and have a few > simple questions. Hi Peter, I am a newbie too, but I have recently dealt with the same issues. > 1) What are the differences between 'constant' and 'targetconstant', > 'globaladdress' and 'targetglobaladdress'? It is not clear from

On Tue, Jun 21, 2016 at 12:31 AM, Matthias Braun <matze at braunis.de> wrote: > I just discussed this with vivek on IRC (and I think we agreed on this): > > Let me first state the motivation clearly to ease later discussions: > As far as the motivation for this change goes: Changing the calling > convention allows us to choose whether a register is saved by the callee or >

On Feb 12, 2008, at 5:26 PM, Chuck Rose III wrote: > Hola LLVMers, > > I’m debugging through some strangeness that I’m seeing on X64 on > windows with LLVM2.2. I had to change the code so that it would > engage the x64 target machine on windows builds, but I’ve otherwise > left LLVM 2.2 alone. The basic idea is that I’ve got a function bar > which is compiled by

----- Original Message ----- > From: "James Molloy via llvm-dev" <llvm-dev at lists.llvm.org> > To: "Vaivaswatha Nagaraj" <vn at compilertree.com> > Cc: "LLVM Dev" <llvm-dev at lists.llvm.org> > Sent: Thursday, December 3, 2015 4:41:46 AM > Subject: Re: [llvm-dev] Function attributes for LibFunc and its impact on GlobalsAA > >

Thanks David, I have tried ‘MF.getFunction()->hasFnAttribute(Attribute::???)’, but it seems that the front-end ‘NoInstrumentFunction’ attribute is not propagated to the collection of LLVM IR attributes (no equivalent is in the ‘Attribute::AttrKind’ enum). It is not obvious that there is another mechanism, and I suspect that there is not due to the separation between FE processing and LLVM

I imagine you can get the llvm::Function from the MachineFunction, and the attribute will be there (on the llvm::Function), but can't say I know much about it. On Tue, Dec 20, 2016 at 2:04 AM Martin J. O'Riordan via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Is it possible to find whether a function has the ‘noinstrument’ > attribute during Target lowering? I would like

Hola LLVMers, I'm debugging through some strangeness that I'm seeing on X64 on windows with LLVM2.2. I had to change the code so that it would engage the x64 target machine on windows builds, but I've otherwise left LLVM 2.2 alone. The basic idea is that I've got a function bar which is compiled by VStudio and I'm creating another function foo via LLVM JIT which is going

Hi Victor, this code from the verifier broke the Ada front-end build: const Module* M = CI.getParent()->getParent()->getParent(); Constant *MallocFunc = M->getFunction("malloc"); if (CI.getOperand(0) == MallocFunc) { const PointerType *PTy = PointerType::getUnqual(Type::getInt8Ty(CI.getParent()->getContext())); Assert1(CI.getType() == PTy, "Malloc