search for: visitgetelementptr

It looks like I need to be able to intercept GEP lowering (in SelectionDAGLowering::visitGetElementPtr) and insert something else other than the shifts and adds. The basic problem is that CellSPU loads and stores on 16-byte boundaries. Consequently, the SPU backend has to do the load or store differently than most normal architectures that have byte-addressable operations. Unfortunately, de...

On Aug 28, 2007, at 7:02 AM, Dan Gohman wrote: > On Mon, Aug 27, 2007 at 07:26:55PM -0700, Scott Michel wrote: >> It looks like I need to be able to intercept GEP lowering (in >> SelectionDAGLowering::visitGetElementPtr) and insert something else >> other than the shifts and adds. The basic problem is that CellSPU >> loads and stores on 16-byte boundaries. Consequently, the SPU backend >> has to do the load or store differently than most normal >> architectures that have byte-addressable op...

On Thu, Dec 8, 2011 at 3:29 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > Ok, thanks, this makes sense. But there is no way to get the SelectionDAG to > do it for me via something like visitGetElementrPtr? SelectionDAGBuilder::visitGetElementPtr uses the same algorithm you want to use, but it is specialized for building a SelectionDAG, which is lower level than LLVM IR. -Eli > > > On Thu, Dec 8, 2011 at 2:54 PM, Eli Friedman <eli.friedman at gmail.com> wrote: >> >> > On Thu, Dec 8, 2011 at 2:37 PM, Ryan Tayl...

...elementptr %bob* %pbob1 ;pbob2 aliases pbob1 %pbobel = getelementptr %bob* %pbob2, long 0, ubyte 0 %rval = load int* %pbobel ret int %rval } Crashes when run through opt -instcombine. InstCombiner visits instructions in reverse declaration order, but InstCombiner::visitGetElementPtr() , when trying to combine %pbobel with %pbob2, assumes that aliases like %pbob2 have already been eliminated. The result is a dereference of an invalid iterator, and an attempt to replace %pbobel with "getelementptr %bob* %pbob1, ubyte 0". ACTION: When combining constant index expr...

On Mon, Aug 27, 2007 at 07:26:55PM -0700, Scott Michel wrote: > It looks like I need to be able to intercept GEP lowering (in > SelectionDAGLowering::visitGetElementPtr) and insert something else > other than the shifts and adds. The basic problem is that CellSPU > loads and stores on 16-byte boundaries. Consequently, the SPU backend > has to do the load or store differently than most normal > architectures that have byte-addressable operations...

...get-which-needs-custom-lowering-for-gep-how-do-i-do-this states quite clearly that some additional work must be done for this sort of architecture. Is this still true? Is there a project/branch to make it more flexible? Support for any memory addressing? I had a short look at SelectionDAGBuilder::visitGetElementPtr(const User &I) and either this method handles it properly already or customization with some target attributes should not be difficult. And what means "a lot of code in the backend" in the link above? Which other parts are involved? Thanks, Boris

Ok, thanks, this makes sense. But there is no way to get the SelectionDAG to do it for me via something like visitGetElementrPtr? On Thu, Dec 8, 2011 at 2:54 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > > On Thu, Dec 8, 2011 at 2:37 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > >> > >> Thanks. > >> > >> So basically then this

On Aug 28, 2007, at 6:15 PM, Scott Michel wrote: > On Aug 28, 2007, at 7:02 AM, Dan Gohman wrote: > >> On Mon, Aug 27, 2007 at 07:26:55PM -0700, Scott Michel wrote: >>> It looks like I need to be able to intercept GEP lowering (in >>> SelectionDAGLowering::visitGetElementPtr) and insert something else >>> other than the shifts and adds. The basic problem is that CellSPU >>> loads and stores on 16-byte boundaries. Consequently, the SPU >>> backend >>> has to do the load or store differently than most normal >>> architecture...

...stom-lowering-for-gep-how-do-i-do-thisstates quite clearly that some additional work must be done for this sort > of architecture. Is this still true? Is there a project/branch to make it > more flexible? Support for any memory addressing? > > I had a short look at SelectionDAGBuilder::visitGetElementPtr(const User > &I) and either this method handles it properly already or customization > with some target attributes should not be difficult. > Yes, you're right. > > And what means "a lot of code in the backend" in the link above? Which > other parts are invol...

...an at gmail.com> wrote: > On Thu, Dec 8, 2011 at 3:29 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > > Ok, thanks, this makes sense. But there is no way to get the > SelectionDAG to > > do it for me via something like visitGetElementrPtr? > > SelectionDAGBuilder::visitGetElementPtr uses the same algorithm you > want to use, but it is specialized for building a SelectionDAG, which > is lower level than LLVM IR. > > -Eli > > > > > > > On Thu, Dec 8, 2011 at 2:54 PM, Eli Friedman <eli.friedman at gmail.com> > wrote: > >> > &g...

I have a platform that I am targeting that has 64-bit general purpose registers but uses 32-bit pointers (ie, sizeof(void*) == 4) but unfortunately it also requires that the top 32-bits of the pointer value be clear. This sometimes becomes a problem with certain pointer calculations such as using a 32-bit negative value for indexing into an array can cause the upper bits to be set, generating

...efault address space. In SelectionDAG * Add a new API to getIntPtrConstant that takes an address space as the second argument * Modify the implementation of the original getIntPtrConstant function to call the new function with getDefaultAddressSpace(). Modify SelectionDAGBuilder::visitGetElementPtr to get the address space of pointer argument and passing it into the getIntrPtrConstant and getPointerTy calls. As far as I can tell, this should not affect any backends behavior, but will allow the targets with disjoint address spaces to directly address them in the most efficient manner. So, wh...

...till applies. Moreover, the vast majority of pointer offsets come from GEPs and they don't map cleanly to either nsw or nuw semantics provided by the DAG. Pointers are fundamentally unsigned objects, but the offsets are signed; so you only get nuw when you can prove the offset is positive (see visitGetElementPtr in SelectionDAGBuilder.cpp). That leaves inbounds GEPs, which theoretically map very cleanly to the addressing modes: we know there's no wrapping at any precision so we don't have to extend everything, and GEP defines offsets to be signed constants, so we can use sxtw. The second major is...

The IR after LSR is: *** IR Dump After Loop Strength Reduction *** ; Preheader: entry: tail call void @fill_array(i32* getelementptr inbounds ([10 x i32], [10 x i32]* @buffer, i32 0, i32 0)) #2 br label %while.body ; Loop: while.body: ; preds = %while.body, %entry %lsr.iv = phi i32 [ %lsr.iv.next, %while.body ], [ 0, %entry ] %uglygep = getelementptr

I’m taking a first look at InstCombine performance. I picked up the caching patch and ran a few experiments on one of our larger C++ apps. The size of the *.0.2.internalize.bc no-debug IR is ~ 30M. Here are my observations so far. Interestingly, caching produced a slight but measurable performance degradation of -O3 compile time. InstCombine takes about 35% of total execution time, of which ~20%

...odeGen.a(EBCTargetMachine.cpp.o) "llvm::TargetData::getStructLayout(llvm::StructType const*) const", referenced from: EmitGlobalConstantStruct(llvm::ConstantStruct const*, unsigned int, llvm::AsmPrinter&)in libLLVMAsmPrinter.a(AsmPrinter.cpp.o) llvm::SelectionDAGBuilder::visitGetElementPtr(llvm::User const&)in libLLVMSelectionDAG.a(SelectionDAGBuilder.cpp.o) GetBaseWithConstantOffset(llvm::Value*, long long&, llvm::TargetData const&)in libLLVMScalarOpts.a(GVN.cpp.o) DecomposeGEPExpression(llvm::Value const*, long long&, llvm::SmallVectorImpl<(anonymous...