search for: issafetoloaduncondit

Hi, There are several optimizations where we try to load speculatively. There are also two similar functions to determine whether it's a safe transformation: * isSafeToLoadUnconditionally * isSafeToSpeculativelyExecute isSafeToLoadUnconditionally tries to take load alignment into account but fails to do this in some cases. It checks alignment for pointers derived from allocas and global variables. But in other cases it scans the local BB to see if the pointer is already bein...

...hus, will not be > > null). Do we currently have a way to pass this information to LLVM? > > No, but I'm interested in this. C++ references imply that 'n' bytes > of the pointer may be dereferenced, and we have no way of capturing > that fact. It would feed into llvm::isSafeToLoadUnconditionally(). At the risk of starting yet another metadata proposal discussion, shall we add some metadata to describe this? These cases could be handled by metadata with an integer parameter. Is there a reasonable way of handling cases like: void foo(int n, int q[n][n]) { ... } ? -Hal > > N...

...gt;>> null). Do we currently have a way to pass this information to LLVM? >> >> No, but I'm interested in this. C++ references imply that 'n' bytes >> of the pointer may be dereferenced, and we have no way of capturing >> that fact. It would feed into llvm::isSafeToLoadUnconditionally(). > > At the risk of starting yet another metadata proposal discussion, shall > we add some metadata to describe this? These cases could be handled by > metadata with an integer parameter. How about function attributes? Is there a reasonable way of > handling cases like:...

...bytes in length (and, thus, will not be null). Do we > currently have a way to pass this information to LLVM? No, but I'm interested in this. C++ references imply that 'n' bytes of the pointer may be dereferenced, and we have no way of capturing that fact. It would feed into llvm::isSafeToLoadUnconditionally(). Nick

Hello, clang currently seems to generate the same code for both: double something_a(char A[const static 256]) { ... } and for: double something_b(char (*const A)) { ... } even though in the first case the programmer has told us that the array A is at least 256 bytes in length (and, thus, will not be null). Do we currently have a way to pass this information to LLVM? Thanks again, Hal

...in libLLVMSelectionDAG.a(LegalizeDAG.cpp.o) (anonymous namespace)::SelectionDAGLegalize::EmitStackConvert(llvm::SDValue, llvm::EVT, llvm::EVT, llvm::DebugLoc) in libLLVMSelectionDAG.a(LegalizeDAG.cpp.o) llvm::isSafeToLoadUnconditionally(llvm::Value*, llvm::Instruction*, unsigned int, llvm::TargetData const*)in libLLVMAnalysis.a(Loads.cpp.o) llvm::DAGTypeLegalizer::SplitVecRes_INSERT_VECTOR_ELT(llvm::SDNode*, llvm::SDValue&, llvm::SDValue&)in libLLVMSelectionDAG.a(LegalizeVectorTypes.cpp.o) llvm::InstrEmi...

Thanks, Ashutosh. Yes, either TTI or TLI could be used to limit the transform if we do it in CGP rather than the DAG. The real question I have is whether it is legal to read the extra memory, regardless of whether this is a masked load or something else. Note that the x86 backend already does this, so either my proposal is ok for x86, or we're already doing an illegal optimization: define

...nWithNewAddressSpace 14 llvm::Function::getParamByValType 14 llvm::InstCombiner::visitAddrSpaceCast 13 llvm::isSafeToLoadUnconditionally 13 isVectorPromotionViableForSlice 12 llvm::ARMTargetLowering::getTgtMemIntrinsic 12 getVectorType...

...in libLLVMSelectionDAG.a(LegalizeDAG.cpp.o) (anonymous namespace)::SelectionDAGLegalize::EmitStackConvert(llvm::SDValue, llvm::EVT, llvm::EVT, llvm::DebugLoc) in libLLVMSelectionDAG.a(LegalizeDAG.cpp.o) llvm::isSafeToLoadUnconditionally(llvm::Value*, llvm::Instruction*, unsigned int, llvm::TargetData const*)in libLLVMAnalysis.a(Loads.cpp.o) llvm::DAGTypeLegalizer::SplitVecRes_INSERT_VECTOR_ELT(llvm::SDNode*, llvm::SDValue&, llvm::SDValue&)in libLLVMSelectionDAG.a(LegalizeVectorTypes.cpp.o) llvm::InstrEmi...