search for: getpointeraddressspace

...at we replace load of null pointer by unreachable only for address space 0. But there is also code doing the following transformation for all the address spaces: // load (select (cond, null, P)) -> load P if(isa<ConstantPointerNull>(SI->getOperand(1)) && LI.getPointerAddressSpace() == 0) { LI.setOperand(0, SI->getOperand(2)); return &LI; } Is this a bug? Would the correct behavior be to check that the pointers' address space is 0? Cheers, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lis...

...ull pointer by unreachable only for address > space 0. But there is also code doing the following transformation for > all the address spaces: > > // load (select (cond, null, P)) -> load P > > if(isa<ConstantPointerNull>(SI->getOperand(1)) && > > LI.getPointerAddressSpace() == 0) { > > LI.setOperand(0, SI->getOperand(2)); > > return &LI; > > } > > > > Is this a bug? Would the correct behavior be to check that the > pointers’ address space is 0? But it does, no? it has && LI.getPointerAddressSpace() == 0 -Hal...

...Type *DataTy = VectorType::get(ScalarDataTy, VF); Value *Ptr = LI ? LI->getPointerOperand() : SI->getPointerOperand(); unsigned Alignment = LI ? LI->getAlignment() : SI->getAlignment(); + if (Alignment == 0) + Alignment = 1; unsigned AddressSpace = Ptr->getType()->getPointerAddressSpace(); unsigned ScalarAllocatedSize = DL->getTypeAllocSize(ScalarDataTy); unsigned VectorElementSize = DL->getTypeStoreSize(DataTy)/VF; Should fix this. On Nov 15, 2013, at 3:49 PM, Joshua Klontz <josh.klontz at gmail.com> wrote: > Nadav, > > I believe aligned accesses to...

...eed to check pointers in the same alias set. if (RtCheck.Pointers[i].AliasSetId != RtCheck.Pointers[j].AliasSetId) continue; Value *PtrI = RtCheck.Pointers[i].PointerValue; Value *PtrJ = RtCheck.Pointers[j].PointerValue; unsigned ASi = PtrI->getType()->getPointerAddressSpace(); unsigned ASj = PtrJ->getType()->getPointerAddressSpace(); if (ASi != ASj) { LLVM_DEBUG( dbgs() << "LAA: Runtime check would require comparison between" " different address spaces\n"); return false...

...static unsigned getMemInstAddressSpace(Value *I) { assert((isa<LoadInst>(I) || isa<StoreInst>(I)) && "Expected Load or Store instruction"); if (auto *LI = dyn_cast<LoadInst>(I)) return LI->getPointerAddressSpace(); return cast<StoreInst>(I)->getPointerAddressSpace(); } -----Original Message----- From: Justin Bogner [mailto:justin at justinbogner.com] On Behalf Of Justin Bogner Sent: Tuesday, February 06, 2018 10:58 AM To: Saito, Hideki via llvm-dev <llvm-dev at lists.llvm.org> Cc: Sai...

...Only need to check pointers in the same alias set. if (RtCheck.Pointers[i].AliasSetId != RtCheck.Pointers[j].AliasSetId) continue; Value *PtrI = RtCheck.Pointers[i].PointerValue; Value *PtrJ = RtCheck.Pointers[j].PointerValue; unsigned ASi = PtrI->getType()->getPointerAddressSpace(); unsigned ASj = PtrJ->getType()->getPointerAddressSpace(); if (ASi != ASj) { LLVM_DEBUG( dbgs() << "LAA: Runtime check would require comparison between" " different address spaces\n"); return false;...

...) > + Alignment = 1; That may be conservatively correct, but I don't think it is really right. An alignment of 0 is supposed to mean the platform default alignment (IIRC, DataLayout::getPrefTypeAlignment tells you what it is). -Hal > unsigned AddressSpace = Ptr->getType()->getPointerAddressSpace(); > unsigned ScalarAllocatedSize = DL->getTypeAllocSize(ScalarDataTy); > unsigned VectorElementSize = DL->getTypeStoreSize(DataTy)/VF; > > Should fix this. > > On Nov 15, 2013, at 3:49 PM, Joshua Klontz <josh.klontz at gmail.com> > wrote: > > > Na...

...> > That may be conservatively correct, but I don't think it is really right. An alignment of 0 is supposed to mean the platform default alignment (IIRC, DataLayout::getPrefTypeAlignment tells you what it is). > > -Hal > >> unsigned AddressSpace = Ptr->getType()->getPointerAddressSpace(); >> unsigned ScalarAllocatedSize = DL->getTypeAllocSize(ScalarDataTy); >> unsigned VectorElementSize = DL->getTypeStoreSize(DataTy)/VF; >> >> Should fix this. >> >> On Nov 15, 2013, at 3:49 PM, Joshua Klontz <josh.klontz at gmail.com> >>...

...k at some of the optimizations/transforms and there are some that we definitely want to keep. Just a quick example from grepping: lib/Transforms/Scalar/LoopIdiomRecognize.cpp ........... // Don't create memset_pattern16s with address spaces. StorePtr->getType()->getPointerAddressSpace() == 0 && (PatternValue = getMemSetPatternValue(StoredVal, DL))) { // It looks like we can use PatternValue! return LegalStoreKind::MemsetPattern; } Even worse, Sanitizers do NOT work with address spaces which is a big deal breaker IMO. Since address spaces and null...

...nsforms and there are some that > we definitely want to keep. > > Just a quick example from grepping: > lib/Transforms/Scalar/LoopIdiomRecognize.cpp > ........... > // Don't create memset_pattern16s with address spaces. > StorePtr->getType()->getPointerAddressSpace() == 0 && > (PatternValue = getMemSetPatternValue(StoredVal, DL))) { > // It looks like we can use PatternValue! > return LegalStoreKind::MemsetPattern; > } > > Even worse, Sanitizers do NOT work with address spaces which is a big deal > breaker I...

...d(gep null, ...) -> unreachable if (GetElementPtrInst *GEPI = dyn_cast<GetElementPtrInst>(Op)) { const Value *GEPI0 = GEPI->getOperand(0); // TODO: Consider a target hook for valid address spaces for this xform. if (isa<ConstantPointerNull>(GEPI0) && GEPI->getPointerAddressSpace() == 0){ // Insert a new store to null instruction before the load to indicate // that this code is not reachable. We do this instead of inserting // an unreachable instruction directly because we cannot modify the // CFG. new StoreInst(UndefValue::get(LI.getType()),...

"Saito, Hideki via llvm-dev" <llvm-dev at lists.llvm.org> writes: > LLVM friends, > > I'm currently trying to make LoopVectorizationLegality class in > Transform/Vectorize/LoopVectorize.cpp more modular and eventually move > it to Analysis directory tree. It uses several file scope helper > functions that do not really belong to LoopVectorize. Let me start

...; > we definitely want to keep. > > > > Just a quick example from grepping: > > lib/Transforms/Scalar/LoopIdiomRecognize.cpp > > ........... > > // Don't create memset_pattern16s with address spaces. > > StorePtr->getType()->getPointerAddressSpace() == 0 && > > (PatternValue = getMemSetPatternValue(StoredVal, DL))) { > > // It looks like we can use PatternValue! > > return LegalStoreKind::MemsetPattern; > > } > > > > Even worse, Sanitizers do NOT work with address spaces whic...

...that >> we definitely want to keep. >> >> Just a quick example from grepping: >> lib/Transforms/Scalar/LoopIdiomRecognize.cpp >> ........... >> // Don't create memset_pattern16s with address spaces. >> StorePtr->getType()->getPointerAddressSpace() == 0 && >> (PatternValue = getMemSetPatternValue(StoredVal, DL))) { >> // It looks like we can use PatternValue! >> return LegalStoreKind::MemsetPattern; >> } >> >> Even worse, Sanitizers do NOT work with address spaces which is a bi...

...ant to keep. > >> > >> Just a quick example from grepping: > >> lib/Transforms/Scalar/LoopIdiomRecognize.cpp > >> ........... > >> // Don't create memset_pattern16s with address spaces. > >> StorePtr->getType()->getPointerAddressSpace() == 0 && > >> (PatternValue = getMemSetPatternValue(StoredVal, DL))) { > >> // It looks like we can use PatternValue! > >> return LegalStoreKind::MemsetPattern; > >> } > >> > >> Even worse, Sanitizers do NOT work with...

LLVM friends, I'm currently trying to make LoopVectorizationLegality class in Transform/Vectorize/LoopVectorize.cpp more modular and eventually move it to Analysis directory tree. It uses several file scope helper functions that do not really belong to LoopVectorize. Let me start from getPointerOperand(). Within LLVM, there are five other similar functions defined. I think it's time to

The GEP constructor does not assert that the source and destination types match. Of course, this is incorrect and causes random failures somewhere down the line. Could I add general sanity checks to the GEP constructor? In general, is an Instruction allowed to be in an inconsistent state? If so, is there some well known method to "verify" whether an instruction is consistent or not?

On 19 April 2018 at 22:36, Manoj Gupta via llvm-dev <llvm-dev at lists.llvm.org> wrote: > I was looking around for the cases where AddrSpace !=0 are checked. Seems > like there are a bunch of optimizations that will fail to apply for non zero > address spaces. Isn't that exactly what we want? Did you look in enough detail to determine that these optimizations *should* have

Is copy.0 semantically equivalent to copy.1 in the following example? define void @copy.0(i8 addrspace(1)* addrspace(1)* %src, i8 addrspace(1)* addrspace(1)* %dst) { entry: %val = load i8 addrspace(1)* addrspace(1)* %src store i8 addrspace(1)* %val, i8 addrspace(1)* addrspace(1)* %dst ret void } define void @copy.1(i8 addrspace(1)* addrspace(1)* %src, i8 addrspace(1)* addrspace(1)* %dst)

Nadav, I believe aligned accesses to unaligned pointers is precisely the issue. Consider the function `add_u8S` before[1] and after[2] the loop vectorizer pass. There is no alignment assumption associated with %kernel_data prior to vectorization. I can't tell if it's the loop vectorizer or the codegen at fault, but the alignment assumption seems to sneak in somewhere. v/r, Josh [1]