search for: minalign

Displaying 10 results from an estimated 10 matches for "minalign".

Did you mean: min_align
2009 Jan 09
2
[LLVMdev] RFC: Store alignment should be LValue alignment, not source alignment
...tCastToType(Ptr, - PointerType::getUnqual(ConvertType(TREE_TYPE(exp)))); + const Type *ATy = cast<PointerType>(ArrayAddr->getType())- >getElementType(); + const Type *ElementTy = cast<ArrayType>(ATy)->getElementType(); + unsigned Alignment = MinAlign(ArrayAlign, TD.getABITypeSize(ElementTy)); + return LValue(BitCastToType(Ptr, + PointerType::getUnqual(ConvertType(TREE_TYPE(exp)))), + Alignment); } // If we are indexing over a fixed-size type, just use a GEP. - if (isSequentialCompatibl...
2017 May 16
4
Which pass should be propagating memory copies
Consider the following IR example: define void @simple([4 x double] *%ptr, i64 %idx) { %stack = alloca [4 x double] %ptri8 = bitcast [4 x double] *%ptr to i8* %stacki8 = bitcast [4 x double] *%stack to i8* call void @llvm.memcpy.p0i8.p0i8.i32(i8 *%stacki8, i8 *%ptri8, i32 32, i32 0, i1 0) %dataptr = getelementptr inbounds [4 x double], [4 x double] *%ptr, i32 0, i64 %idx
2009 Jan 09
0
[LLVMdev] RFC: Store alignment should be LValue alignment, not source alignment
...ArrayAlign = ArrayAddrLV.Alignment; Couldn't this be expr_align(Array)? > + const Type *ATy = cast<PointerType>(ArrayAddr->getType())- > >getElementType(); > + const Type *ElementTy = cast<ArrayType>(ATy)->getElementType(); > + unsigned Alignment = MinAlign(ArrayAlign, > TD.getABITypeSize(ElementTy)); Why these manipulations? These happens several more times below. > @@ -6028,8 +6063,9 @@ static unsigned getComponentRefOffsetInB > > LValue TreeToLLVM::EmitLV_COMPONENT_REF(tree exp) { > LValue StructAddrLV = EmitLV(TREE_OPERA...
2018 Mar 26
1
Change memcpy/memmove/memset to have dest and source alignment attributes
...pass updates were conservative, and could potentially be made more aggressive by a motivated individual — list below. All that remains is for interested folk to enhance lowering of small memcpy/memmove into load/store sequences. The lowering in SelectionDAG currently just conservatively uses the MinAlign() of the source & dest alignments as the alignment for the loads and stores. I suspect that we could do better by teaching the lowering that the source & dest can have different alignments. Note that, also, the createMem[Cpy|Move]Loop type functions used in the LowerMemIntrinsics pass are...
2004 Feb 06
4
memory reduction
.../* cum. bytes allocated */ + uint64 b_freed; /* cum. bytes freed */ +}; + +struct pool_extent +{ + void *start; /* starting address */ + size_t free; /* free bytecount */ + size_t bound; /* bytes bound by padding, + * overhead and freed */ + struct pool_extent *next; +}; + +#define MINALIGN (sizeof (void *)) + +alloc_pool_t +pool_create(size_t size, size_t quantum, + void (*bomb)(char *), int flags) +{ + struct alloc_pool *pool; + + if (!(pool = (struct alloc_pool*) malloc(sizeof (struct alloc_pool)))) + return pool; + memset(pool, 0, sizeof (struct alloc_pool)); + + pool->size...
2018 Apr 02
0
Change memcpy/memmove/memset to have dest and source alignment attributes
...ative, and could > potentially be made more aggressive by a motivated individual — list below.  > >  All that remains is for interested folk to enhance lowering of small > memcpy/memmove into load/store sequences. The lowering in SelectionDAG currently > just conservatively uses the MinAlign() of the source & dest alignments as the > alignment for the loads and stores. I suspect that we could do better by > teaching the lowering that the source & dest can have different alignments. > >  Note that, also, the createMem[Cpy|Move]Loop type functions used in the > Lo...
2018 Jan 02
5
Change memcpy/memmove/memset to have dest and source alignment attributes
Good day all, I’ve spent a few days resurrecting the circa-2015 work on removing the explicit alignment argument (4th arg) from the @llvm.memcpy/memmove/memset intrinsics in favour of using the alignment attribute on the pointer args of calls to the intrinsic. This work was first proposed back in August 2015 by Lang Hames: http://lists.llvm.org/pipermail/llvm-dev/2015-August/089384.html (item
2009 May 21
0
[LLVMdev] [PATCH] Add new phase to legalization to handle vector operations
On Wed, May 20, 2009 at 4:55 PM, Dan Gohman <gohman at apple.com> wrote: > Can you explain why you chose the approach of using a new pass? > I pictured removing LegalizeDAG's type legalization code would > mostly consist of finding all the places that use TLI.getTypeAction > and just deleting code for handling its Expand and Promote. Are you > anticipating something more
2009 May 20
2
[LLVMdev] [PATCH] Add new phase to legalization to handle vector operations
On May 20, 2009, at 1:34 PM, Eli Friedman wrote: > On Wed, May 20, 2009 at 1:19 PM, Eli Friedman > <eli.friedman at gmail.com> wrote: > >> Per subject, this patch adding an additional pass to handle vector >> >> operations; the idea is that this allows removing the code from >> >> LegalizeDAG that handles illegal types, which should be a significant
2009 May 21
2
[LLVMdev] [PATCH] Add new phase to legalization to handle vector operations
...Tmp2 = DAG.getNode(ISD::ADD, dl, Tmp2.getValueType(), Tmp2, - DAG.getIntPtrConstant(IncrementSize)); - assert(isTypeLegal(Tmp2.getValueType()) && - "Pointers must be legal!"); - SVOffset += IncrementSize; - Alignment = MinAlign(Alignment, IncrementSize); - Hi = DAG.getStore(Tmp1, dl, Hi, Tmp2, ST->getSrcValue(), - SVOffset, isVolatile, Alignment); - Result = DAG.getNode(ISD::TokenFactor, dl, MVT::Other, Lo, Hi); - break; - } // case Expand - } } else { -...