search for: d37579

...If this seems impractical, I'd certainly like to understand why. (*) CodeMetrics has a way to collect "ephemeral values" to avoid extra values affecting some of the cost modeling, but they still block optimization. Thanks again, Hal > I updated > https://reviews.llvm.org/D37579 and https://reviews.llvm.org/D37648 > with adding the aggregate pointer as second parameter as Michael > asked. So now, the intrinsic look like this: > > void phantom_mem(any_pointer base, any_pointer aggregate, uint64_t > maximum_offset) > > For PR21780, I don't need to us...

...at which there was reference by its type in a function. After InstCombine deleted the load operation, it could be restored in SLPVectorizer and we could restore chains of GEPs, Loads and Inserts in case we encounter phatom_mem intrinsic. Here is two part review: https://reviews.llvm.org/D37579 - InstCombine part. https://reviews.llvm.org/D37648 - SLP part. Also, there might be different approaches in describing deleted memory operations, for example, for my case: phantom_load(llvm_anyptr_ty, llvm_i64_ty). First parameter describes pointer and second parameter offset from point...

...e remaining loads indicating that it would be legal to widen them? no, I don't have any concerns about intrinsic way of implementation, and intrinsic way looks safer for me since we somehow detach our information about memory from that actual load instruction. I updated https://reviews.llvm.org/D37579 and https://reviews.llvm.org/D37648 with adding the aggregate pointer as second parameter as Michael asked. So now, the intrinsic look like this: void phantom_mem(any_pointer base, any_pointer aggregate, uint64_t maximum_offset) For PR21780, I don't need to use aggregate so it is set to null,...

...Combine deleted the load operation, it could be >>> restored in SLPVectorizer and we could restore chains of GEPs, Loads >>> and Inserts in case we encounter phatom_mem intrinsic. >>> >>> Here is two part review: >>> https://reviews.llvm.org/D37579 - InstCombine part. >>> https://reviews.llvm.org/D37648 - SLP part. >>> >>> Also, there might be different approaches in describing deleted memory >>> operations, for example, for my case: phantom_load(llvm_anyptr_ty, >>> llvm_i64_ty). First p...

...ad operation, it could be >>>> restored in SLPVectorizer and we could restore chains of GEPs, Loads >>>> and Inserts in case we encounter phatom_mem intrinsic. >>>> >>>> Here is two part review: >>>> https://reviews.llvm.org/D37579 - InstCombine part. >>>> https://reviews.llvm.org/D37648 - SLP part. >>>> >>>> Also, there might be different approaches in describing deleted memory >>>> operations, for example, for my case: phantom_load(llvm_anyptr_ty, >>>>...

...by its type in a > function. After InstCombine deleted the load operation, it could be > restored in SLPVectorizer and we could restore chains of GEPs, Loads > and Inserts in case we encounter phatom_mem intrinsic. > > Here is two part review: > https://reviews.llvm.org/D37579 - InstCombine part. > https://reviews.llvm.org/D37648 - SLP part. > > Also, there might be different approaches in describing deleted memory > operations, for example, for my case: phantom_load(llvm_anyptr_ty, > llvm_i64_ty). First parameter describes pointer and second par...