search for: getargu

...I would like to know that the second argument is a pointer to type struct.ta, and hence the size of memory allocated to that pointer is 4 bytes. I understand that the second argument to memcpy intrinsic namely i8* bitcast (%struct.ta* @t1 to i8*) is a ConstantExpression (CE). When I dump CE->getArgument(0), I get the following. @t1 = global %struct.ta zeroinitializer, align 4 But from here, I am not able to find the relevant class/API to extract the type of CE->getArgument(0) and hence the size of it. When I tried CE->getArgument(0)->getType(), I am getting the type as Pointer and h...

...ter is 4 > bytes. > You should be able to use the stripPointerCasts() method of llvm::Value * to strip off the bitcast. > I understand that the second argument to memcpy intrinsic namely i8* > bitcast (%struct.ta* @t1 to i8*) is a ConstantExpression (CE). When I > dump CE->getArgument(0), I get the following. > > @t1 = global %struct.ta zeroinitializer, align 4 > > But from here, I am not able to find the relevant class/API to extract > the type of CE->getArgument(0) and hence the size of it. When I tried > CE->getArgument(0)->getType(), I am get...

...of them to LLVM's ADT specifically to address the immediate needs of range-based for loops. > > Sounds good. We also have to decide what to do with Function::arg_begin() for example (and all the other secondary ranges hanging off IR and other things). IMO, "for (auto &arg : F.getArguments())" makes the most sense. > > I was actually going to check in this, but I can post it for review if folks are worried. > > My plan was to provide an implementation of std::iterator_range<T> and then provide 'F.arguments()' which returns it. Nice. What's...

...selection of them to LLVM's ADT specifically to address the immediate needs of range-based for loops. Sounds good. We also have to decide what to do with Function::arg_begin() for example (and all the other secondary ranges hanging off IR and other things). IMO, "for (auto &arg : F.getArguments())" makes the most sense. -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140302/cd9fb4ce/attachment.html>

...ke it work both backward (to support GVN) and forward (to support DSE). In the meantime, enhancing memcpyopt is fine, so long as there are good testcases (and your patch has them!). Nit picky stuff about the patch: + for(unsigned argI = 0; argI < CS.arg_size(); ++argI) { + if(CS.getArgument(argI)->stripPointerCasts() == pointer) Please put spaces after if/for. You get this right in some places, but wrong in others. + Value* pointer = L->getPointerOperand(); Please use "Value *pointer" style throughout. It looks like MemCpyOpt is already really inconsisten...

Hello, This patch fixes PR2218. However, I'm not pretty sure that this optimization should be in MemCpyOpt. I think that GVN is good place as well. Regards -- Jakub Staszak -------------- next part -------------- A non-text attachment was scrubbed... Name: pr2218.patch Type: application/octet-stream Size: 6146 bytes Desc: not available URL:

...o I compile c code from a char array in clang? Im using code from the interpreter example. Thanks. char *cCode; // the char array // fill array with code goes here... // Initialize a compiler invocation object from the clang (-cc1) arguments. const driver::ArgStringList &CCArgs = Cmd->getArguments(); llvm::OwningPtr<CompilerInvocation> CI(new CompilerInvocation); CompilerInvocation::CreateFromArgs(*CI, const_cast<const char **>(CCArgs.data()), const_cast<const char **>(CCArgs.data()) +...

...pport GVN) and forward (to support DSE). In the > meantime, enhancing memcpyopt is fine, so long as there are good > testcases (and your patch has them!). > > Nit picky stuff about the patch: > > + for(unsigned argI = 0; argI < CS.arg_size(); ++argI) { > + if(CS.getArgument(argI)->stripPointerCasts() == pointer) > > Please put spaces after if/for. You get this right in some places, > but wrong in others. > > + Value* pointer = L->getPointerOperand(); > > Please use "Value *pointer" style throughout. It looks like > Me...

...preter example. >> Thanks. >> >> char *cCode; // the char array >> // fill array with code goes here... >> >> >> // Initialize a compiler invocation object from the clang (-cc1) >> arguments. >> const driver::ArgStringList &CCArgs = Cmd->getArguments(); >> llvm::OwningPtr<CompilerInvocation> CI(new CompilerInvocation); >> CompilerInvocation::CreateFromArgs(*CI, >> const_cast<const char >> **>(CCArgs.data()), >> const_cast<...

...ing to locate all instances of a specific function call, identify one of it arguments and find where it was declared and defined. i can visit every instruction in each function, identify the appropriate CallInst, get the CallSite of the instruction and extract the appropriate (Value) argument with getArgument(X). Unfortunately I can't figure out how to get from the Value of the argument to its definition/assignment site. I would ideally like to be able to display its original value and the line number of the assignment. To complicate matters further, the variable's a character array. I'...

...g? > > Im using code from the interpreter example. > Thanks. > > char *cCode; // the char array > // fill array with code goes here... > > > // Initialize a compiler invocation object from the clang (-cc1) arguments. > const driver::ArgStringList &CCArgs = Cmd->getArguments(); > llvm::OwningPtr<CompilerInvocation> CI(new CompilerInvocation); > CompilerInvocation::CreateFromArgs(*CI, > const_cast<const char > **>(CCArgs.data()), > const_cast<const char > **&g...

Hello, I have been using the USE class to access the use-def chains of different values. However, what I have noticed is that the set of users of a particular value is limited for the appearance of that variable in the current function. How can I get the interprocedural use of a particular value? For example, if a variable *a* is used as an argument in a function call *foo*, the USE analysis

...gt;>> >>> char *cCode; // the char array >>> // fill array with code goes here... >>> >>> >>> // Initialize a compiler invocation object from the clang (-cc1) >>> arguments. >>> const driver::ArgStringList &CCArgs = Cmd->getArguments(); >>> llvm::OwningPtr<CompilerInvocation> CI(new CompilerInvocation); >>> CompilerInvocation::CreateFromArgs(*CI, >>> const_cast<const char >>> **>(CCArgs.data()), >>>...

...s actually going to check in this, but I can post it for review if folks are worried. >> >> My plan was to provide an implementation of std::iterator_range<T> and then provide 'F.arguments()' which returns it. > > Nice. What's the logic behind .arguments() vs .getArguments()? I don't have a strong opinion either way, but there should be rationale. > > In the best case 'get' doesn't really add any meaning, and in the worst case it is actively misleading It's getting the range though, just like Function::getArgumentList() returns the a...

...better in the future :( This patch is looking like a great improvement. Some comments on formatting: Please pull this out to a helper function: + CallSite CS = CallSite::get(C); + + // Pointer must be a parameter (case 1) + for (argI = 0; argI < CS.arg_size(); ++argI) + if (CS.getArgument(argI)->stripPointerCasts() == pointer) + break; + + if (argI == CS.arg_size()) + return false; per http://llvm.org/docs/CodingStandards.html#hl_predicateloops + // Store cannot be volatile (case 2) and must-alias with our pointer. + if (S->isVolatile()) { + return...

Hi Everyone, I asked a question on the dev list related to the topic to which John Criswell and Jeremy Lakeman kindly provided some valuable insight. I'm still stuck on the issue and i'm hoping i didn't phrase the question well enough. I have a *foo.c* file that is : *#include <stdio.h>* *int foo(int a, int b){* * return a+b;* *}* *int main() {* *int x=foo(3,1); *

I would like to instrument certain function calls with a function call of my own that takes some of the same arguments. For example, I would like to instrument calls to free with some function foo, so the C code would look like: foo(myarg1, myarg2, ptr); free(ptr); The problem occurs when I grab the arg from the free function and try to pass it to foo... if (isCallToFree(&I)) { Value*

Scott Ricketts wrote: > I would like to instrument certain function calls with a function call > of my own that takes some of the same arguments. For example, I would > like to instrument calls to free with some function foo, so the C code > would look like: > > foo(myarg1, myarg2, ptr); > free(ptr); > > The problem occurs when I grab the arg from the free function and

..., no globals return AliasAnalysis::getModRefBehavior(F, Info); } ModRefResult getModRefInfo(CallSite CS, Value *P, unsigned Size) { std::string functionName = CS.getCalledFunction()->getNameStr(); if(_srets.find(functionName) != _srets.end()) { if(CS.hasArgument(P)) { if(CS.getArgument(0) == P) return AliasAnalysis::Mod; // modify value pointed to by sret param else return AliasAnalysis::NoModRef; // there aren't any other pointer args } } return AliasAnalysis::getModRefInfo(CS, P, Size); } bool hasNoModRefInfoForCalls() const { return false; } };...

...;(*Jobs.begin()); if (llvm::StringRef(Cmd->getCreator().getName()) != "clang") { Diags.Report(diag::err_fe_expected_clang_command); return 1; } // Initialize a compiler invocation object from the clang (-cc1) arguments. const driver::ArgStringList &CCArgs = Cmd->getArguments(); llvm::OwningPtr<CompilerInvocation> CI(new CompilerInvocation); CompilerInvocation::CreateFromArgs(*CI, const_cast<const char **>(CCArgs.data()), const_cast<const char **>(CCArgs.data()) +...