search for: hasprefixdata

At the bottom of < http://llvm.org/docs/doxygen/html/classllvm_1_1Function.html>, it says "Generated on Sat Nov 16 2013", but the hasPrefixData/getPrefixData functions don't seem to be there (I just happened to notice those being missing). Even going directly to the header source code at < http://llvm.org/docs/doxygen/html/Function_8h_source.html> doesn't seem to have them? Is doxygen reusing some stale state on the server...

...library on top of the target-dependent facilities provided in IR. One could imagine a set of routines like this: /// Given some constant data, attach valid prefix data. void attachPrefixData(Function *F, Constant *Data); /// Returns an i1 indicating whether prefix data is present for FP. Value *hasPrefixData(Value *FP); /// Returns a pointer to the prefix data for FP. Value *getPrefixDataPointer(Value *FP, Type *DataType); > Forcing clients to embed deep > target-specific-machine-code knowledge in their frontends seems like a step > in the wrong direction for LLVM. Given a set of routines s...

Firstly, do you need "main.dsp" defined as an external symbol, or can all external references go via "main"? If the answer is the latter, that will make the solution simpler. If only the latter, you will need to make a change to LLVM here: http://llvm-cs.pcc.me.uk/lib/CodeGen/AsmPrinter/AsmPrinter.cpp#650 Basically you would need to add a hook to the TargetLoweringObjectFile

...endent facilities provided in IR. One could imagine a set > of routines like this: > > /// Given some constant data, attach valid prefix data. > void attachPrefixData(Function *F, Constant *Data); > > /// Returns an i1 indicating whether prefix data is present for FP. > Value *hasPrefixData(Value *FP); > > /// Returns a pointer to the prefix data for FP. > Value *getPrefixDataPointer(Value *FP, Type *DataType); > > > Forcing clients to embed deep > > target-specific-machine-code knowledge in their frontends seems like a > step > > in the wrong directio...

On Wed, Jul 17, 2013 at 6:06 PM, Peter Collingbourne <peter at pcc.me.uk>wrote: > Hi, > > I would like to propose that we introduce a mechanism in IR to allow > arbitrary data to be stashed before a function body. The purpose of > this would be to allow additional data about a function to be looked > up via a function pointer. Two use cases come to mind: > > 1)

Hi, I would like to propose that we introduce a mechanism in IR to allow arbitrary data to be stashed before a function body. The purpose of this would be to allow additional data about a function to be looked up via a function pointer. Two use cases come to mind: 1) We'd like to be able to use UBSan to check that the type of the function pointer of an indirect function call matches the