similar to: [LLVMdev] Text or Data symbol

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

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

Hi Sanjiv, The PIC16TargetAsmInfo::getBSSSectionForGlobal apparently does magic that reinterprets the "section" field of a global in a strange way: // If GV has a sectin name or section address create that section now. if (GV->hasSection()) { std::string SectName = GV->getSection(); // If address for a variable is specified, get the address and create

Substituting the uses of a global with an absolute address would make all accesses to that global through pointer, which is very inefficient on PIC16. So we don't change the code generation for that global; instead we only pass the address information to the linker (home made linker) through some assembly directives. What are you trying to do? Are you trying to change the logic of this part or

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

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

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

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,

I've prepared a preliminary patch with the intention of implementing PPC-EABI subtarget features for applications that run in a standalone embedded environment. https://reviews.llvm.org/D26344 The most significant difference compared with the SVR4 ABI is the use of SDA (small data area). This allows full-word constants and data to be grouped into small-data sections accessed using relocated

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

----- Original Message ----- > From: "Jack Andersen via llvm-dev" <llvm-dev at lists.llvm.org> > To: "llvm-dev" <llvm-dev at lists.llvm.org> > Sent: Wednesday, November 16, 2016 10:39:53 PM > Subject: Re: [llvm-dev] [MC] Target-Independent Small Data Section Handling > > Just pinging this patch for review, particularly from PPC > maintainers:

Just pinging this patch for review, particularly from PPC maintainers: https://reviews.llvm.org/D26344 It's now rebased for the latest master commits, `check-all` test results match those of the upstream base. There is also a clang driver patch, extending PPC target support for the `-G` flag: https://reviews.llvm.org/D26345 And lld patch implementing the _SDA_BASE_ symbols and includes an

Attached is a working patch set for llvm to be able to emit arm64 (currently as triple aarch64-apple-ios) mach-o object files, in case someone is interested. I'm not sure if the llvm maintainers want the patch given the previous message that there's going to be an official patch set from apple to support this, but here is mine. What works (tested on an iPhone 5S): * objc strings,

Hi all, I wanted to summarise some discussion on llvm-commits [0,1] as an RFC, as I felt it demanded wider circulation. Our support for references to absolute symbols is not very good. The symbol will be resolved accurately in non-PIC code, but suboptimally: the symbol reference cannot currently appear as the immediate operand of an instruction, and the code generator cannot make any assumptions

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