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 {
-...