search for: addressspaces

Hellp One of the data members of class PointerType  is [unsigned] AddressSpace What is its role? I didn`t find sufficient description about it in the LLVM documentation. Could someone please point me where can I get description about different AddressSpaces? What I saw that address spaces may affect how optimizations are performed –Where can I get more information about this issue. Thank you

Every GlobalAddress has a GlobalValue, Every GlobalValue is a PointerType, Every PointerType has an AddressSpace. So is it ok to add a method getAddressSpace in GlobalAddressSDNode class itself? Currently we have to do GSDN->getGlobal()->getType()->getAddressSpace(). - Sanjiv

What is the proper solution to disable auto-vectorization for unaligned data? I have an out of tree target and I added this: bool OpusTargetLowering::allowsUnalignedMemoryAccesses(EVT VT, bool *Fast) const { if (VT.isVector()) return false; .... } After that, I could see that vectorization is still done on unaligned data except that llvm will copy the data back and forth from the source

Mon Ping, Thanks for the tip, but I can't for the life of me seem to get the Value from a StoreSDNode. From looking at the SelectionDAGNodes header file, the only class that has the getValue function call is SrcValueSDNode that returns a Value type. The only class that has getType is a ConstantPoolSDNode. I don't think that ConstantPoolSDNode is what I want and when I try to cast the

Hello, It seems I stepped on a bug with the ConstantMerge IPO pass, regarding address spaces. For example, if a module contains the following: @a = internal constant i16 224 @b = internal addrspace(30) constant i16 224 Although a & b have the same initializer, i think they should not be merged. Attempting to do it anyway will trigger an assertion. I guess the safe and easy way is to only

...> > +}; > > If we are going to standardise these address space numbers across > Clang and the LLVM backends, this enum declaration should be added > somewhere in LLVM so that the backends have access to it. Perhaps a > new header file called something like "llvm/Support/AddressSpaces.h"? We went for llvm/Support/OpenCL.h for now, because might need to add further OpenCL-specific support. Copying to llvmdev. > > +enum OpenCLImageAccess { > > + OPENCL_READ_ONLY = 1, > > + OPENCL_WRITE_ONLY = 2, > > + OPENCL_READ_WRITE = 3 > > +}; > >...

On Thu, 13 Sep 2007 Alireza.Moshtaghi at microchip.com wrote: > I think it all boils down to whether you think it is time to incorporate > these extensions into LLVM IR and how long do you think it will take to > do so? Sure, any time is good. The reason we don't have this now is primarily because noone has stepped up to contribute it. If you're like to start this, I'd be

On Sep 12, 2007, at 6:41 PM, <Alireza.Moshtaghi at microchip.com> <Alireza.Moshtaghi at microchip.com> wrote: > Chris, > Extending LLVM IR to support PointerTypes that take an address > space is > what I was hoping to avoid. However, if we want to do things right, > that > is probably the way to go. Now that we got here, let me write some > of my >

I am using llvm-2.6. In the online documentation, the signature is GlobalVariable::GlobalVariable ( const Type * Ty, bool isConstant, LinkageTypes Linkage, Constant * Initializer = 0, const Twine & Name = "", bool ThreadLocal = false, unsigned AddressSpace = 0 ) the link to the documenation is

Thank you Chris and Christopher, I agree... the Embedded C Language Extensions report provides a good foundation to build on, and what it proposes as far as Address Space is probably a super set of what we have in our existing compiler (and probably would like to keep) so no conflict there. I also agree that regardless of how we would like to deal with pointers, the same extensions must be applied

On Jul 19, 2013, at 3:14 PM, Francois Pichet <pichet2000 at gmail.com> wrote: > > What is the proper solution to disable auto-vectorization for unaligned data? > > I have an out of tree target and I added this: > > bool OpusTargetLowering::allowsUnalignedMemoryAccesses(EVT VT, bool *Fast) const { > if (VT.isVector()) > return false; > .... > } >

...> > If we are going to standardise these address space numbers across > > Clang and the LLVM backends, this enum declaration should be added > > somewhere in LLVM so that the backends have access to it. Perhaps a > > new header file called something like "llvm/Support/AddressSpaces.h"? > We went for llvm/Support/OpenCL.h for now, because might need to add further > OpenCL-specific support. Copying to llvmdev. I don't think we should include the word OpenCL in the name of this enum/header. We may very well in the future want to define address space constants...

On Fri, Jul 19, 2013 at 1:14 PM, Francois Pichet <pichet2000 at gmail.com> wrote: > > What is the proper solution to disable auto-vectorization for unaligned > data? Why are you trying to do this? If auto-vectorization is making a given loop slower on your target, that means the cost metrics are off, and we should fix them. If code size is an issue, you should tell the optimizer

Hello all, I recently finished merging the last 3.5 months of upstream changes into our CHERI LLVM fork and would like to suggest something to both simplify our future merges and also avoid bugs for targets such as AVR that use non-zero pointer address spaces. We make extensive use of address spaces: all our pointers (CHERI capabilities) use address space 200 instead of the default zero to

Ok any quick workaround to limit vectorization to 16-byte aligned 128-bit data then? All the memory copying done by ExpandUnalignedStore/ExpandUnalignedLoad is just too expensive. On Sat, Jul 20, 2013 at 12:52 PM, Arnold Schwaighofer < aschwaighofer at apple.com> wrote: > > On Jul 19, 2013, at 3:14 PM, Francois Pichet <pichet2000 at gmail.com> wrote: > > > > >

Using an rsync (V2.5.6, Tru64 Unix 5.1A) command of the form: rsync -avz --delete /some/dir remhost:/some/other/dir where /some/dir has about 460,000 files in it, I get: building file list ... done ERROR: out of memory in make_file rsync error: error allocating core memory buffers (code 22) at /usr/common/src/rsync-2.5.6/util.c(115) rsync: connection unexpectedly closed (8 bytes read so far)

For a datapoint, Julia uses the following function description to implement approximately the capability of those functions. We then also verify that there's no direct inttoptr/ptrtoint into our gc-tracked AddressSpace with a custom verifier pass (among other sanity checks). I can provide additional details and pointers to our gc-root tracking algorithm implementation if desired (I also plan

...clude the word OpenCL in the name of this >> enum/header.  We may very well in the future want to define address >> space constants for other languages, which should not overlap with >> the OpenCL constants, by extending this enum. > Good point.  We have defined in llvm/Support/AddressSpaces.h: > > +namespace llvm { > +  namespace AddressSpaces { > +    enum AddressSpace { > +      PRIVATE = 0, > +      GLOBAL = 1, > +      LOCAL = 2, > +      CONSTANT = 3 > +    }; > +  } > +} The address space mechanism is used by some code generators to differentiat...

The address qualifier is stored in the type of %result. From that operand, you can get the Value and then call getType. The type for result should be a PointerType which you cast to a PointerType and get the getAddressSpace e.g. cast<PointerType>(Ty)->getAddressSpace() -- Mon Ping On Sep 17, 2008, at 1:06 PM, Villmow, Micah wrote: > How do I access the address qualifier

Something like: index 6db7f68..68564cb 100644 --- a/lib/Transforms/Vectorize/LoopVectorize.cpp +++ b/lib/Transforms/Vectorize/LoopVectorize.cpp @@ -1208,6 +1208,8 @@ void InnerLoopVectorizer::vectorizeMemoryInstruction(Instr Type *DataTy = VectorType::get(ScalarDataTy, VF); Value *Ptr = LI ? LI->getPointerOperand() : SI->getPointerOperand(); unsigned Alignment = LI ?