search for: ispointerti

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

i am using llvm , i did this if ( AllocaInst *allocInst = dyn_cast<AllocaInst>(&*bbit)){ PointerType *p = allocInst->getType(); if ( p->getElementType()->isPointerTy()){ StringRef name = allocInst->getName();

I want to know the type of pointer . for example if we have int *p, struct node *w char *q then i want int for p,char for q , struct node for w. any help would be appreciated. -- View this message in context: http://llvm.1065342.n5.nabble.com/How-To-Get-The-Name-of-the-type-the-popinter-is-pointing-to-tp49121.html Sent from the LLVM - Dev mailing list archive at Nabble.com.

Hello, I was wondering how you can identify whether or not an Argument is a pointer. The "isDereferenceablePointer" function for Values doesn't seem to be what I want (I don't care whether or not the pointer points to allocated memory or is suitably aligned). I want to be able to discern between: i32* %pArray and i32 %pArray Thanks in advance. - John

Hi all, as a LLVM beginner I would like to know how can i check the pointer types with different levels like int 32* and int 32**, int 32***? By using value->getType()->isPointerTy() i can just know they are pointers. But the dump results clearly show they are different. Is there a good way to calculate their actual point to levels? Thanks! Best regards, Shen -------------- next part

I am seeing an assert when I compile the attached program with clang: $ clang -fno-strict-aliasing -target mips64el-unknown-linux -O3 -fomit-frame-pointer -S test1.c -o test1.ll -emit-llvm It asserts when LoopVectorize.cpp:506 is executed. It looks like it is complaining because it is trying to zero-extend an i64 (type Count->getType() returns i64) to an i32 (IdxTy). if (Count->getType()

this is definitely a bug in AA. 225 for (auto I = CS2.arg_begin(), E = CS2.arg_end(); I != E; ++I) { 226 const Value *Arg = *I; 227 if (!Arg->getType()->isPointerTy()) -> 228 continue; 229 unsigned CS2ArgIdx = std::distance(CS2.arg_begin(), I); 230 auto CS2ArgLoc = MemoryLocation::getForArgument(CS2, CS2ArgIdx, TLI);

Hi All, I am trying to check if a Value type is a int32 pointer by using if(T == Type::getInt1PtrTy(Context, AS)) ... I am trying to understand the AS (address space). How do I get it? Thanks. George * * -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110606/775e4f09/attachment.html>

On 6 June 2011 17:08, George Baah <georgebaah at gmail.com> wrote: > if(T == Type::getInt1PtrTy(Context, AS)) ... Hi, You don't need to care about address spaces to check for an int32*: if (T->isPointerTy()) { const Type* intT = cast<PointerType>(T)->getElementType(); if (intT->isIntegerTy() && intT->getPrimitiveSizeInBits() == 32) cout <<

You can use isPointerTy() in Type class. George On Mon, Aug 20, 2012 at 12:39 PM, John Backes <back0145 at umn.edu> wrote: > Hello, > > I was wondering how you can identify whether or not an Argument is a > pointer. The "isDereferenceablePointer" function for Values doesn't > seem to be what I want (I don't care whether or not the pointer points > to

Please file a bug for these types of issues. On Fri, Dec 21, 2012 at 1:49 PM, Akira Hatanaka <ahatanak at gmail.com> wrote: > I am seeing an assert when I compile the attached program with clang: > > $ clang -fno-strict-aliasing -target mips64el-unknown-linux -O3 > -fomit-frame-pointer -S test1.c -o test1.ll -emit-llvm > > > It asserts when LoopVectorize.cpp:506 is

John, thanks for you answer! But as far as I know LLVM doesn't provide any interface for finding the pointee of a pointer directly, so i have to process a multi-level pointer i need to write my own function to check pointers level by level, is that right? On Fri, Jul 17, 2015 at 1:47 PM, John Criswell <jtcriswel at gmail.com> wrote: > On 7/17/15 12:38 PM, Shen Liu wrote: > >

On 11 June 2017 at 12:05, Tim Northover <t.p.northover at gmail.com> wrote: > On 11 June 2017 at 11:56, Dipanjan Das via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > I can't pass var_value to a function accepting uint64_t. LLVM complains > > about broken function call. > > Well, yes. var_value has type "ConstantInt *", not uint64_t. Assuming

On Wednesday 04 Apr 2012 12:41:49 Patrik Hägglund H wrote: > Hi Tim, > > > So I've come to the conclusion that the real flaw is LLVM > > not exposing enough information to the target-dependent > > backend code for it to do the right thing. > > We also had this problem. You might find this patch useful as a starting > point:

+ a few others. After following this rabbit hole a bit, there are a lot of mutually recursive calls, etc, that may or may not do the right thing with vectors of pointers. I can fix *this* particular bug with the attached patch. However, it's mostly papering over stuff. Nothing seems to know what to do with a memorylocation that is a vector of pointers. They all expect memorylocation to be a

Hi Thomson, the new call to puts() is inserted right away, whereas the old call to printf() is removed a bit later in SimplifyLibCalls::runOnFunction(). If you browse the code a bit and backtrack the call stack to see what happens with the return value of PrintFOpt::OptimizeFixedFormatString(), you will stumble upon this segment in SimplifyLibCalls.cpp:1703ff.: // Try to optimize this call.

On Wed, Dec 12, 2012 at 01:59:55PM -0800, Dan Gohman wrote: > The bug here isn't in clang's use of noalias or in BasicAliasAnalysis' > implementation of noalias; it's in the code that's optimizing the > icmp. Let's come back to this. The attached patch decouples InstSimplify from the alias analysis and provides the conservative logic for when pointers are not

Hi all, I am working on my Master's project in security and I am trying to iterate over the argument list of the function. Basically I need to do following things : 1. Check data type of each argument of the argument list of the function. 2. Based on its data type like character array or integer array, pointer, int, char, take different action. 3. I have added following code to check its

John, thanks for your helpful advice. My ultimate goal is to construct a full instruction-level program dependence graph for a given IR file. The hard point is how to establish the correct data dependence edges when some function arguments are multi-level pointers. To solve this problem I hope to check the point-to level for each pointer variable. I think the data dependence through pointers can

On 11 June 2017 at 14:04, don hinton <hintonda at gmail.com> wrote: > Assuming you know it's a 64 bit value, and the function you are calling > takes a uint64_t, try this: > The values from the test program are of type: i32/i32*/i32**. Can't I interpret these as uint64_t some way? > > Value* args[] = {store_inst->getOperand(0)}; > > > On Sun, Jun 11,