search for: pointee

...@@ -399,10 +399,16 @@ void TypePrinter::printMemberPointerBefore(const MemberPointerType *T, raw_ostream &OS) { IncludeStrongLifetimeRAII Strong(Policy); SaveAndRestore<bool> NonEmptyPH(HasEmptyPlaceHolder, false); - printBefore(T->getPointeeType(), OS); + + // Suppress the printing of implied calling conventions. + QualType Pointee = T->getPointeeType(); + if (const AdjustedType *AT = dyn_cast<AdjustedType>(Pointee)) + Pointee = AT->getOriginalType(); + + printBefore(Pointee, OS); // Handle things like 'int (C...

On Mon, Dec 9, 2013 at 5:18 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > Mingw switched abis with the release of gcc 4.7 > (http://gcc.gnu.org/gcc-4.7/changes.html). The main change is that now > mingw (like msvc) given thiscall calling convention to methods by > default. > > I think the last bug blocking us to support the new abi has just been > fixed.

...2014 at 4:22 PM, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- > > From: "Frank Winter" <fwinter at jlab.org> > > To: llvmdev at cs.uiuc.edu > > Sent: Tuesday, March 25, 2014 9:23:59 AM > > Subject: Re: [LLVMdev] Alignment of pointee > > > > On 03/25/2014 10:08 AM, Krzysztof Parzyszek wrote: > > > On 3/25/2014 8:53 AM, Frank Winter wrote: > > >> > > >> One can see that if the initial alignment of the pointee of %arg0 > > >> was 32 > > >> bytes and since the ve...

....memcpy does a full memcpy, unless decorated by metadata, which can specify that some of the bytes are undefined. There is an appeal in having a base IR which is simple, with metadata for making it more aggressive in tricky ways. I can also see the appeal of overloading @llvm.memcpy with different pointee types. An interesting issue is the semantics in the case where the pointee types have holes. For example: %struct = type { i8, i32 } call void @llvm.memcpy.mangledstuff(%struct* %dst, %struct* %src, i64 1, i64 4) It should always be valid to lower @llvm.memcpy to an actual memcpy call, but w...

"Doerfert, Johannes via llvm-dev" <llvm-dev at lists.llvm.org> writes: > We could use a custom tag on `llvm.assume`, as an extension of > https://reviews.llvm.org/D72475, but that is not yet implemented. I had thought about using llvm.assume but was wondering if there is a better way. Tagging the loads with metadata really seems about the same amount of effort. Both

...val/llvm-dev/cyRZyXcMCNI https://groups.google.com/forum/#!topicsearchin/llvm-dev/$20byval/llvm-dev/uk4uiK93jeM https://groups.google.com/forum/#!topicsearchin/llvm-dev/byval/llvm-dev/46Tv0lSRwBg and read through code (as best I can) but I am no wiser. I am using the XCore target where the pointee data needs to be copied by the callee (not the caller). So: > I am not sure what this means though - when I generate code > from the LLVM assembly, do I need to do anything with byval? yes, the pointee needs to be passed by-copy, which usually means on the sta...

On 03/25/2014 10:08 AM, Krzysztof Parzyszek wrote: > On 3/25/2014 8:53 AM, Frank Winter wrote: >> >> One can see that if the initial alignment of the pointee of %arg0 was 32 >> bytes and since the vectorizer operates on a loop with a fixed trip >> count of 4 and the size of double is 8 bytes, the vector loads and >> stores could be ideally aligned with 32 bytes (which on my target >> architecture would result in vector loads with...

...%44, align 8 %132 = fadd <4 x double> %wide.load, %wide.load54 %364 = getelementptr double* %arg0, i64 %93 %365 = bitcast double* %364 to <4 x double>* store <4 x double> %329, <4 x double>* %365, align 8 } } One can see that if the initial alignment of the pointee of %arg0 was 32 bytes and since the vectorizer operates on a loop with a fixed trip count of 4 and the size of double is 8 bytes, the vector loads and stores could be ideally aligned with 32 bytes (which on my target architecture would result in vector loads without additional permutations. Is...

...s of type PointerType are unlike the other SequentialTypes (arrays and vectors) in that they do not hold values of the element type. By moving PointerType we can unify certain aspects of how the other SequentialTypes are handled. - PointerType will have no place in the SequentialType hierarchy once pointee types are removed, so this is a necessary step towards removing pointee types. Although this would slightly complicate GEP enumeration, this can be handled at the API level and is also inevitable given the move to remove pointee types. Specifically I want to change the API exposed by the GEP type...

Hi all, i am coding to analyze an IR with multi-level pointers, and i am eager to know whether there exists a way to find the pointee pointer directly, if only given an upper level pointer. For example, in the following demo, C code: int i = 10; int *p = &i; int **pp; *pp = &p; IR code: %i = alloca i32, align 4 %p = alloca i32*, align 8 %pp = alloca i32**, align 8 store i32 10, i32* %i, align 4 store...

On Aug 27, 2012, at 12:58 PM, Hal Finkel <hfinkel at anl.gov> wrote: > On Mon, 27 Aug 2012 11:41:47 -0700 > Dan Gohman <gohman at apple.com> wrote: >> On Aug 24, 2012, at 10:50 PM, Hal Finkel <hfinkel at anl.gov> wrote: >> >>> On Wed, 22 Aug 2012 13:15:30 -0700 >>> Dan Gohman <gohman at apple.com> wrote: >>> >>>>

...is context mean? It means the pointer value itself satisfies isa<Constant>. > Is that > assumption violated if I explicitly cast away const and pass the result > to a function with NoAlias argument? Not immediately, no. It means that you can't access the constant pointer's pointee directly within the noalias argument's scope. Access to that object must go through the noalias argument. Restrict on a pointer loosely means "All accesses to my pointee(s) in my scope must go through me". It doesn't mean "I'm the only pointer value in the program which...

While checking for serialization/deserialization without using pointee types, I've come across a few test cases that crash at head, without my debugging assertions for accessing pointee types. One of them is test/Transforms/StripSymbols/2010-06-30-StripDebug.ll Its retainedTypes metadata points to a metadata array of a single null element. This crashes the dyn_...

LLVM developers, I was wondering if the program would still be safe if I strip the byval attributes from the parameters in the entire bitcode. LLVM language reference manual states that "The attribute implies that a hidden copy of the pointee is made between the caller and the callee, so the callee is unable to modify the value in the callee. This attribute is only valid on LLVM pointer arguments." Is there a way I can avoid the byval attribute by a custom transformation? I was thinking of a custom transformation that introduces a...

...the difference is though. :) >> > > Should have said: > >> Should I take the same approach to the encoding of pointer types in >> the types table? PointerTypes are a bit easier. The code to write them looks like this: case Type::PointerTyID: // POINTER: [pointee type] Code = bitc::TYPE_CODE_POINTER; TypeVals.push_back(VE.getTypeID(cast<PointerType>(T)- >getElementType())); The code to read them look like this: case bitc::TYPE_CODE_POINTER: // POINTER: [pointee type] if (Record.size() < 1) return Error(&...

On Tue, Dec 11, 2012 at 03:17:43AM -0800, Chandler Carruth wrote: > As Joerg pointed out in IRC, 'y' is an lvalue, but we do not use it to > access the object it designates, we only use it to compute the address, and > thus restrict should have no bearing on it. That would in turn make Clang's > optimization incorrect and also seems likely to make 'noalias'

...quentialTypes (arrays >> and vectors) in that they do not hold values of the element type. By moving >> PointerType we can unify certain aspects of how the other SequentialTypes >> are handled. >> - PointerType will have no place in the SequentialType hierarchy once >> pointee types are removed, so this is a necessary step towards removing >> pointee types. >> >> Although this would slightly complicate GEP enumeration, this can be >> handled at the API level and is also inevitable given the move to remove >> pointee types. >> >>...

...as fewer instructions after all -- but I don't think that's the right approach for two reasons: 1) It will be a *very* narrow canonicalization that only works with overly specific sets of casted pointers. 2) It doesn't effectively move us toward the optimizer treating IR with different pointee types for pointer types indistinguishably. Some day, I continue to think we should get rid of the pointee types entirely. To see why #1 and #2 are problematic, assume another round of inlining took place and we suddenly had the following IR: AFAICT, this is the same and we still don't have a...

...unlike the other SequentialTypes (arrays > and vectors) in that they do not hold values of the element type. By moving > PointerType we can unify certain aspects of how the other SequentialTypes > are handled. > - PointerType will have no place in the SequentialType hierarchy once > pointee types are removed, so this is a necessary step towards removing > pointee types. > > Although this would slightly complicate GEP enumeration, this can be > handled at the API level and is also inevitable given the move to remove > pointee types. > > Specifically I want to chang...

Hi Robert, > I tried adding to the XCoreCallingConv.td: > CCIfByVal<CCPassByVal<0,4>> // pushes pointer to the stack This looks sensible to me. After that it comes down to cooperation between XCoreISelLowering's LowerFormalArguments and LowerCall functions. LowerFormalArguments is at the beginning of a function and is responsible for taking arguments out of