search for: globalvalues

Hi, could anybody explain what GlobalValue::AvailableExternallyLinkage means? I implemented an instrumentation pass that creates a clone of a function. For some programs I noticed that also function such as “atoi”, “atof”, “__strspn_c2”, etc. they get cloned even if I am not implementing them in the module. I would like to avoid cloning those functions, so I noticed that they have

I was about to post a bug concerning this, but I thought I'd check with you folks first. The symptom is a SIGSEGV in my program in the standard library template for red black trees (bits/stl_tree.h). The crash occurs as the result of an LLVM Module method, getConstantPointerRef which looks like: // Accessor for the underlying GlobalValRefMap... ConstantPointerRef

Is there a way to distinguish between GlobalValues that are user-defined and those that are compiler-defined? I am looking for a function that I can use to tell if a GlobalValue is user-defined , something like "GlobalValue::isUserDefined", which returns true for user-defined GlobalValue. I'm trying to make changes to prevent llvm fr...

...Object Function GlobalVariable I think that this would be better for (e.g.) the X86 backend anyway, since global objects can be assigned to specific addresses with linker maps, and thus have small addresses (and this is expressible with the range metadata). This means that GlobalConstant and other GlobalValues should all be usable in the same places in principle. -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161024/0f1ca6b9/attachment.html>

Hi, here I am again with "why is this so" kind of a question. Among different types of MachineOperand there are MO_ExternalSymbol and MO_GlobalAddress. For MO_GlobalAddress, we can get usefull information from the getGlobal() method, which returns GlobalValue*. Wouldn'it it be better is MO_GlobalAddress be called MO_GlobalValue, for consistency? Second, MO_ExternalSymbol is used

...e-lists! Replace them with ref-counts to keep most of >> the use-list API functional (and minimize the size of the change). >> See the WIP patch below (0003). >> >> 3. (Optional) Remove use-lists from other non-GlobalValue Constants >> that do not reference any GlobalValues. This would require some >> sort of magic in, e.g., ConstantVector to conditionally have a >> use-list. > > I wonder if the constant class hierarchy should not be revisited in light of this? > For instance you identified that some are local to a module while others are “c...

When I attempt to follow any tutorial for llvm and add the `llvm-config --cxxflags --ldflags --libs all` line to my GXX_FLAGS, g++ chokes on llvm/GlobalValue.h, complaining of an invalid cast from int to llvm::GlobalValue::LinkageTypes. I receive this error under both Red Hat and Ubuntu and the version of G++ I am using is 4.1.2. Thanks in advance, Jared -------------- next part -------------- An

...w (0001 and 0002). 2. Remove the use-lists! Replace them with ref-counts to keep most of the use-list API functional (and minimize the size of the change). See the WIP patch below (0003). 3. (Optional) Remove use-lists from other non-GlobalValue Constants that do not reference any GlobalValues. This would require some sort of magic in, e.g., ConstantVector to conditionally have a use-list. Call sites of API like Value::use_begin would have to check for Value::hasUseList. 4. (Optional) Remove the ref-count from ConstantData (and, potentially, other use-list-free Consta...

Hi all: I am trying to get the return value of a call instruction that I inserted during the optimization pass I wrote. I have something like the following: CallInst *InitCall = CallInst::Create(InitFn, Args.begin(), Args.end(), "log_load_addr_ret", LI); CastInst *InsertedCast =

Thanks Mehdi. My pass clones the functions within a module in order to have the original function and an exact copy of the same function but with a different name, i.e. sum() and sum_parallel(). After my pass I will run ThreadSanitizer instrumentation pass only on the new copy of the functions, i.e. only the “_parallel” functions will be instrumented by tsan. In some programs that I am

On 10/24/2016 1:07 PM, Peter Collingbourne via llvm-dev wrote: > On Mon, Oct 10, 2016 at 8:12 PM, Peter Collingbourne <peter at pcc.me.uk > <mailto:peter at pcc.me.uk>> wrote: > > The specific change I have in mind is to allow !range metadata on > GlobalObjects. This would > be similar to existing !range metadata, but it would apply to the >

Because what is happening is that if function “atoi” gets cloned I don’t have a definition of “atoi_parallel” therefore I get undefined references when linking. I just want to clone and instrument functions implemented in modules of my program. > On Nov 19, 2016, at 13:54, Mehdi Amini <mehdi.amini at apple.com> wrote: > > >> On Nov 19, 2016, at 12:44 PM, Simone Atzeni

> > On Nov 19, 2016, at 14:09, Mehdi Amini <mehdi.amini at apple.com> wrote: > > I assume from your description that you are also updating call sites in the same module so that if foo was calling atoi, after cloning you have foo_parallel that is calling atoi_parallel? > If this is the issue, it depends, I’d probably consider turning the available_externally into internal.

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

On Thu, 17 Jun 2004, Vladimir Prus wrote: > > Hi, > here I am again with "why is this so" kind of a question. Among different > types of MachineOperand there are MO_ExternalSymbol and MO_GlobalAddress. > > For MO_GlobalAddress, we can get usefull information from the getGlobal() > method, which returns GlobalValue*. Wouldn'it it be better is >

...ction > GlobalVariable > I think that this would be better for (e.g.) the X86 backend anyway, since global objects can be assigned to specific addresses with linker maps, and thus have small addresses (and this is expressible with the range metadata). This means that GlobalConstant and other GlobalValues should all be usable in the same places in principle. > > If this works, it does seem better. But I can imagine it being hard to take the "load" of the global constant and turn it into a direct reference to a symbolic immediate operand to an instruction. The linker “could" do...

...nly local references are: - Argument - Instruction So the following does seem like a feasible minimal step forward: 1. Build a mechanism to break the use dependencies for GlobalValue and BasicBlock, i.e. allow immortal BlockAddress and ConstantGlobalValue values while _also_ allowing us to delete GlobalValues and BasicBlocks. For this mechanism, we can let ourselves be inspired by mlir::SymbolRefAttr, which uses strings for the linkage. Alternatively (and perhaps preferably), we could use a weak_ptr-like mechanism. This can be very efficient, since each GlobalValue and BasicBlock only ever needs to ha...

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

Hello LLVM, To reduce the code-size cost of relocations, I'm trying to hoist GlobalValues that are used many times. A new pass hides each hoisted GV behind a BITCAST in the dominating BB. The pass then updates users with the output of the BITCAST. This pass works properly AFAICT. The problems come in instruction selection. SelectionDAGBuilder::visitBitCast() treats the BITCAST as a...