search for: storedv

Hi, I am currently working on an opencl project based on LLVM, the target device is 32bit. I met a problem that some llvm passes like GVN SROA will generate some IR operating on wide integer types like i128 or i512. But the device does not support such kind of data type. Is there any idea on how to lower this kind of IR to only operate on i32 or vector of i32? Or is there any existing code handle

Some code in GVN.cpp: static Value *CoerceAvailableValueToLoadType(Value *StoredVal, Type *LoadedTy, Instruction *InsertPt, const DataLayout &DL) { .... // Convert vectors and fp to integer, which can be manipulated. if (!StoredValTy->...

.... 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 pointers are really orthogonal issues, I would prefer to not conflate them....

...rom 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. IMO fixing these seems less engineering overhead in the long term than introd...

...ib/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. > > IMO fixing these seems less engin...

...;> 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. > > IMO fixing these seems less engineering overh...

.../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. > > > > IM...

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

On Thu, Apr 19, 2018 at 11:59 AM Friedman, Eli <efriedma at codeaurora.org> wrote: > On 4/19/2018 11:57 AM, Friedman, Eli via cfe-dev wrote: > > On 4/19/2018 11:48 AM, Manoj Gupta via llvm-dev wrote: > > On Wed, Apr 18, 2018 at 12:54 PM Tim Northover <t.p.northover at gmail.com> > wrote: > > > On Wed, Apr 18, 2018 at 12:02 PM Friedman, Eli <efriedma at