search for: functionindex

...I think what I need here is a way of selecting multiple rows and averaging per column (notice that the column number should stay the same) b. I would like to be able to convert strings that are function names to real function calls. For example I have something like LogFunction<- function(){} FunctionIndex<- rbind (c(1,"LogFunction"),                c(2,"TakeFunction")               ) print(sprintf('Using the function %s',FunctionIndex[1,1])) # call the FunctionIndex[1,1] somehow I would like to thank you in advance for your help Regards Alex [[alternative HTML v...

...InByteCode This works fine so far using the standard machinery of LLVM. But some functions are not implemented in byte code, but delegated to native implementations within the VM. Calls to these functions use a non-standard calling convention and should be lowered to another opcode: CALL_NATIVE $functionIndex where $functionIndex is a magic byte telling the VM which native function should be called. As the set of native functions and function indices will be extended over time, it should not be hardcoded into the backend but given as input at compile time. I have some vague ideas on how I could implem...

...t part -------------- Index: include/llvm/IR/Function.h =================================================================== --- include/llvm/IR/Function.h (revision 176874) +++ include/llvm/IR/Function.h (working copy) @@ -181,6 +181,14 @@ AttributeSet::FunctionIndex, N)); } + /// addFnAttr - Add function attributes to this function. + /// + void addFnAttr(StringRef Kind) { + setAttributes( + AttributeSets.addAttribute(getContext(), + AttributeSet::FunctionIndex, Kind)); + } + /// \brief Return true if the fun...

...so far using the standard machinery of LLVM. But some > functions are not implemented in byte code, but delegated to native > implementations within the VM. Calls to these functions use a non- > standard > calling convention and should be lowered to another opcode: > CALL_NATIVE $functionIndex > where $functionIndex is a magic byte telling the VM which native > function > should be called. As the set of native functions and function indices > will > be extended over time, it should not be hardcoded into the backend but > given as input at compile time. > > >...

...One, "VectorGep"); ... packed_gather_params.push_back(vecShuffleOnePtr); CallInst *callGather = Builder.CreateCall(func_llvm_masked_gather_v128i16, packed_gather_params); callGather->addAttribute(AttributeSet::FunctionIndex, Attribute::NoUnwind); DEBUG(dbgs() << "callGather: " << *callGather << "\n"); When running this code we get at stderr something like: callgather: %50 = call <4 x i16> @llvm.masked.gather.v4i16(<4 x i16*> getelementptr (i16,...

...aces the old AttributeList class. The AttributeSet stores a collection of Attribute objects for each kind of object that may have an attribute associated with it: the function as a whole, the return type, or the function's parameters. A function's attributes are at index "AttributeSet::FunctionIndex"; the return type's attributes are at index "AttributeSet::ReturnIndex"; and the function's parameters' attributes are at indices 1, ..., n (where 'n' is the number of parameters). Most methods on the AttributeSet class take an index parameter. An AttributeSet is...

...orGep"); > ... > packed_gather_params.push_back(vecShuffleOnePtr); > CallInst *callGather = Builder.CreateCall(func_llvm_masked_gather_v128i16, > packed_gather_params); > callGather->addAttribute(AttributeSet::FunctionIndex, Attribute::NoUnwind); > > DEBUG(dbgs() << "callGather: " << *callGather << "\n"); > > When running this code we get at stderr something like: > callgather: %50 = call <4 x i16> @llvm.masked.gather.v4i16(<4 x i16*> ge...

...ullptr; + + Module *M = B.GetInsertBlock()->getModule(); + AttributeSet AS[2]; + AS[0] = AttributeSet::get(M->getContext(), 1, Attribute::NoCapture); + Attribute::AttrKind AVs[2] = { Attribute::ReadOnly, Attribute::NoUnwind }; + AS[1] = AttributeSet::get(M->getContext(), AttributeSet::FunctionIndex, AVs); + + LLVMContext &Context = B.GetInsertBlock()->getContext(); + Constant *StrNLen = M->getOrInsertFunction( + "strnlen", AttributeSet::get(M->getContext(), AS), + DL.getIntPtrType(Context), B.getInt8PtrTy(), DL.getIntPtrType(Context), nullptr); + CallInst *...

...un on this function + // (safestack attribute takes precedence) + AttrBuilder B; + B.addAttribute(Attribute::StackProtect) + .addAttribute(Attribute::StackProtectReq) + .addAttribute(Attribute::StackProtectStrong); + F.removeAttributes(AttributeSet::FunctionIndex, AttributeSet::get( + F.getContext(), AttributeSet::FunctionIndex, B)); + } + + if (AA->onlyReadsMemory(&F)) { + // XXX: we don't protect against information leak attacks for now + DEBUG(dbgs() << "[SafeStack] function only reads memory...

...g a bit on each attribute (Akira's proposal) handles > more cases. Nothing needs to be done in `lib/Linker` > (`llc` is able to override the output of `llvm-link`), > and it doesn't have a disconnect between `hasFnAttribute()` > and `getAttributes().hasAttribute(FunctionIndex)`. > > Awkwardly, having written that out, I'm kind of leaning toward > it myself right now (maybe I'm fickle?) -- it seems to have > fewer limitations. The main thing I prefer about my proposal > is that it's easier to change the default attributes when > modifying a...

...; class. The AttributeSet stores a collection of Attribute objects for each > kind > of object that may have an attribute associated with it: the function as a > whole, the return type, or the function's parameters. A function's > attributes > are at index "AttributeSet::FunctionIndex"; the return type's attributes > are at > index "AttributeSet::ReturnIndex"; and the function's parameters' > attributes are > at indices 1, ..., n (where 'n' is the number of parameters). Most methods > on > the AttributeSet class take an index...

Hi Duncan, Been thinking about this a bit and a few comments/questions. I may have misunderstood some things in your mail though so please feel free to explain at me :) > Changing `clang` to store target defaults on the module will allow us to > continue to override them when running `llc`. The right precedence > would be: > > 1. Explicit attributes set on the function. >

...attribute (Akira's proposal) handles >> more cases. Nothing needs to be done in `lib/Linker` >> (`llc` is able to override the output of `llvm-link`), >> and it doesn't have a disconnect between `hasFnAttribute()` >> and `getAttributes().hasAttribute(FunctionIndex)`. >> >> Awkwardly, having written that out, I'm kind of leaning toward >> it myself right now (maybe I'm fickle?) -- it seems to have >> fewer limitations. The main thing I prefer about my proposal >> is that it's easier to change the default attributes w...

> On Aug 20, 2015, at 9:46 AM, Steve King <steve at metrokings.com> wrote: > > On Wed, Aug 19, 2015 at 10:58 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: >> >> Isn’t the problem the fact that the patch makes it harder for a target to >> get the generic code to reach its custom hook? >> Now the "cheap pow2 sdiv” is merged with the generic

...Subtarget(MachineFunction *MF) { + bool ChangeToMips16 = false, ChangeToNoMips16 = false; + DEBUG(dbgs() << "resetSubtargetFeatures" << "\n"); + AttributeSet FnAttrs = MF->getFunction()->getAttributes(); + ChangeToMips16 = FnAttrs.hasAttribute(AttributeSet::FunctionIndex, + "mips16"); + ChangeToNoMips16 = FnAttrs.hasAttribute(AttributeSet::FunctionIndex, + "nomips16"); + assert (!(ChangeToMips16 & ChangeToNoMips16) && + "mips16 and nomips16...

On Thu, Mar 28, 2013 at 12:22 PM, Nadav Rotem <nrotem at apple.com> wrote: > IMHO the right way to handle target function attributes is to > re-initialize the target machine and TTI for every function (if the > attributes changed). Do you have another solution in mind ? I don't really understand this. TargetMachine and TTI may be quite expensive to initialize. Doing so for

...ach attribute (Akira's proposal) handles >> more cases. Nothing needs to be done in `lib/Linker` >> (`llc` is able to override the output of `llvm-link`), >> and it doesn't have a disconnect between `hasFnAttribute()` >> and `getAttributes().hasAttribute(FunctionIndex)`. >> >> Awkwardly, having written that out, I'm kind of leaning toward >> it myself right now (maybe I'm fickle?) -- it seems to have >> fewer limitations. The main thing I prefer about my proposal >> is that it's easier to change the default attributes...

Hello. I come back to this thread. But I want to ask a slightly different question. Is there a way to have LLVM IR language intrinsics that are given at construction time a string that is written at assembly generation time as it is? (so, basically having placeholders of strings in LLVM that remain untouched until the end, including code generation time.) More exactly, I would

Hi, Not sure whether this matches your use case, but the Orc-based JIT used in LLI appears to be using `llvm::orc::LocalCXXRuntimeOverrides` (http://llvm.org/doxygen/classllvm_1_1orc_1_1LocalCXXRuntimeOverrides.html) to override `__cxa_atexit`: https://github.com/llvm-mirror/llvm/blob/release_50/tools/lli/OrcLazyJIT.h#L74

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