search for: getabitypealignment

Yes, I was just about to send out: DL->getABITypeAlignment(ScalarDataTy); The question is: “… ABI alignment for the target …" is that getPrefTypeAlignment or getABITypeAlignment I would have thought the latter. On Nov 15, 2013, at 4:12 PM, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- >> From: "Ar...

...const PointerType *Ty = - PointerType::getUnqual(ConvertType(TREE_TYPE(exp))); - return ConstantPointerNull::get(Ty); + const Type *Ty = ConvertType(TREE_TYPE(exp)); + const PointerType *PTy = PointerType::getUnqual(Ty); + LValue LV(ConstantPointerNull::get(PTy), TD.getABITypeAlignment(Ty)); + return LV; } assert(0 && "INTERNAL ERROR: Referencing decl that hasn't been laid out"); abort(); @@ -5924,7 +5936,13 @@ LValue TreeToLLVM::EmitLV_DECL(tree exp) // type void. if (Ty == Type::VoidTy) Ty = StructType::get(NULL, NULL);...

...gnment than the original. if (Value.getOpcode() == ISD::BIT_CONVERT && !ST->isTruncatingStore() && ST->isUnindexed()) { unsigned Align = ST->getAlignment(); MVT SVT = Value.getOperand(0).getValueType(); unsigned OrigAlign = TLI.getTargetData()-> getABITypeAlignment(SVT.getTypeForMVT()); if (Align <= OrigAlign && ((!LegalOperations && !ST->isVolatile()) || TLI.isOperationLegalOrCustom(ISD::STORE, SVT))) return DAG.getStore(Chain, N->getDebugLoc(), Value.getOperand(0), Ptr, ST->get...

...8, <4 x float>* %204, align 8 > > There is a bug in the SLPVectorizer however - it should be “align 4” - we get the alignment of the pointer type which is not what we want we want the alignment of the stored/loaded value. It should be > > if (!Alignment) > Alignment = DL->getABITypeAlignment(SI->getValueOperand()->getType()); r215162 fixes this bug. > > I am not sure that would fix your issue though, because that would mean we return the wrong alignment not none. > > If the call below returns 0 then something has gone wrong in setting up the data layout in your...

...t; - PointerType::getUnqual(ConvertType(TREE_TYPE(exp))); > - return ConstantPointerNull::get(Ty); > + const Type *Ty = ConvertType(TREE_TYPE(exp)); > + const PointerType *PTy = PointerType::getUnqual(Ty); > + LValue LV(ConstantPointerNull::get(PTy), > TD.getABITypeAlignment(Ty)); > + return LV; If the type is opaque or abstract, won't this assert getting the alignment? You might as well use 1 here, since compilation is going to fail anyway. > @@ -5924,7 +5936,13 @@ LValue TreeToLLVM::EmitLV_DECL(tree exp) > // type void. > if (Ty == Typ...

...Store() && ST->isUnindexed()) { - unsigned Align = ST->getAlignment(); + unsigned OrigAlign = ST->getAlignment(); MVT SVT = Value.getOperand(0).getValueType(); - unsigned OrigAlign = TLI.getTargetData()-> + unsigned Align = TLI.getTargetData()-> getABITypeAlignment(SVT.getTypeForMVT()); if (Align <= OrigAlign && ((!LegalOperations && !ST->isVolatile()) || Does that look right to you? Dan On Wed, February 18, 2009 4:49 pm, David Greene wrote: > I got bit by this in LLVM 2.4 DagCombiner.cpp and it's still in trunk:...

...2. > > case Instruction::Store: { > StoreInst *SI = cast<StoreInst>(VL0); > unsigned Alignment = SI->getAlignment(); > ... > StoreInst *S = Builder.CreateStore(VecValue, VecPtr); > if (!Alignment) > Alignment = DL->getABITypeAlignment(SI->getPointerOperand()->getType()); // << Get the 4byte alignment for the scalar float store from the data layout string. > S->setAlignment(Alignment); -------------- next part -------------- A non-text attachment was scrubbed... Name: module_H7ktW0.ll.gz Type: applicati...

...orIN4llvm16ExecutionContextEE7destroyEPS2_+0x11)[0x84bd7af] ... ... I checked the llvm svn log, this is due to the patch from " svn diff -r43619:43620" The replacement of getABITypeSize with getTypeSize caused it. This seems an alignment unmatch issue. As for type i75, the getABITypeSize/getABITypeAlignment will return 10 while in APInt, it actually allocated two-64bit-array (128bit totally) hence the malloc/free crashed. Ciao, can you take a look at it? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20071203/9...

...gt;isUnindexed()) { > - unsigned Align = ST->getAlignment(); > + unsigned OrigAlign = ST->getAlignment(); > MVT SVT = Value.getOperand(0).getValueType(); > - unsigned OrigAlign = TLI.getTargetData()-> > + unsigned Align = TLI.getTargetData()-> > getABITypeAlignment(SVT.getTypeForMVT()); > if (Align <= OrigAlign && > ((!LegalOperations && !ST->isVolatile()) || > > Does that look right to you? Yes, and it fixes the problem. What's your opinion about how TargetData and X86Subtarget define ABI alignment for S...

...fe of me seem to figure out how to enter this section of code: // If this is an unaligned load and the target doesn't support it, // expand it. if (!TLI.allowsUnalignedMemoryAccesses()) { unsigned ABIAlignment = TLI.getTargetData()-> getABITypeAlignment(LD->getMemoryVT().getTypeForMVT()); if (LD->getAlignment() < ABIAlignment){ Result = ExpandUnalignedLoad(cast<LoadSDNode>(Result.getNode()), DAG, TLI); Tmp1 = Result.getOperand(0);...

...was going to agree - but poking around, it looks like we need alignment >> too, at least (not sure if we need other things beyond size & alignment, >> nothing springs to mind but I don't know much about this stuff) - >> TargetLoweringBase::getByValTypeAlignment/DataLayout::getABITypeAlignment >> > > Nope, we don't, we have an align attribute. =D > Yep, seemed the align attribute wasn't always set in the frontend (& there's a comment in the backend where getByValTypeAlignment is called saying essentially "this is a fallback, it's not always correc...

...errors, like *[xxx at localhost ex]$ llc test.ll -march=SSP -o test.s 0 llc 0x08f7ee49 1 llc 0x08f7f41a 2 0x003b1420 __kernel_sigreturn + 0 3 llc 0x08de0d52 llvm::TargetData::getAlignment(llvm::Type const*, bool) const + 44 4 llc 0x08de108a llvm::TargetData::getABITypeAlignment(llvm::Type const*) const + 44 5 llc 0x0863e289 llvm::TargetData::getTypeAllocSize(llvm::Type const*) const + 37 6 llc 0x08a707ed llvm::GetReturnInfo(llvm::Type const*, unsigned int, llvm::SmallVectorImpl<llvm::ISD::OutputArg>&, llvm::TargetLowering const&, llvm::SmallVec...

...tABITypeAligment(I.getType()) returns 4 if the type is i32 and 8 for i64 type. For testing, I forced it to 8 and the IR example below worked fine. Is there some kind of attributes to force function parameters to be aligned contiguously? Or could it be that va_arg alignment is wrongly made using DL.getABITypeAlignment? Thank's in advance for your help. Regards, Gaël Here's is the IR code for testing: target datalayout = "e-m:w-i64:64-f80:128-n8:16:32:64-S128" target triple = "x86_64-pc-windows-msvc18.0.0" %struct.va_list = type { i8* } $"str" = comdat any @"s...

MCJIT when lowering to x86-64 generates a MOVAPS (Move Aligned Packed Single-Precision Floating-Point Values) on a non-aligned memory address: movaps 88(%rdx), %xmm0 where %rdx comes in as a function argument with only natural alignment (float*). This x86 instruction requires the memory address to be 16 byte aligned which 88 plus something aligned to 4 byte isn't. Here the

----- Original Message ----- > From: "Arnold Schwaighofer" <aschwaighofer at apple.com> > To: "Joshua Klontz" <josh.klontz at gmail.com> > Cc: "LLVM Dev" <llvmdev at cs.uiuc.edu> > Sent: Friday, November 15, 2013 4:05:53 PM > Subject: Re: [LLVMdev] Limit loop vectorizer to SSE > > > Something like: > > index

...t;> - unsigned Align = ST->getAlignment(); >> + unsigned OrigAlign = ST->getAlignment(); >> MVT SVT = Value.getOperand(0).getValueType(); >> - unsigned OrigAlign = TLI.getTargetData()-> >> + unsigned Align = TLI.getTargetData()-> >> getABITypeAlignment(SVT.getTypeForMVT()); >> if (Align <= OrigAlign && >> ((!LegalOperations && !ST->isVolatile()) || >> >> Does that look right to you? > > Yes, and it fixes the problem. Cool. I've committed this on trunk now. If you have a reason...

Is there a way using llvm::TargetData to determine the alignment of what would be equivalent to __attribute__((__aligned__))? I'm looking for something like a max alignment number for the target platform so that I know what the max alignment of an address returned by malloc(...) will be. Thanks in advance Garrison

Something like: index 6db7f68..68564cb 100644 --- a/lib/Transforms/Vectorize/LoopVectorize.cpp +++ b/lib/Transforms/Vectorize/LoopVectorize.cpp @@ -1208,6 +1208,8 @@ void InnerLoopVectorizer::vectorizeMemoryInstruction(Instr Type *DataTy = VectorType::get(ScalarDataTy, VF); Value *Ptr = LI ? LI->getPointerOperand() : SI->getPointerOperand(); unsigned Alignment = LI ?

...tABITypeAligment(I.getType()) returns 4 if the type is i32 and 8 for i64 type. For testing, I forced it to 8 and the IR example below worked fine. Is there some kind of attributes to force function parameters to be aligned contiguously? Or could it be that va_arg alignment is wrongly made using DL.getABITypeAlignment? Thank's in advance for your help. Regards, Gaël Here's is the IR code for testing: target datalayout = "e-m:w-i64:64-f80:128-n8:16:32:64-S128" target triple = "x86_64-pc-windows-msvc18.0.0" %struct.va_list = type { i8* } $"str" = comdat any @"s...

It sounds like your DataLayout may not match clang's for x86_64-linux. What does it say about the alignment of i64? On Wed, Apr 18, 2018 at 12:05 PM edA-qa mort-ora-y via llvm-dev < llvm-dev at lists.llvm.org> wrote: > I'm creating a struct of `{i8,i64}` and `DataLayout::getTypeAllocSize` > is returning `12`. `getStructLayout` also gives an `4` offset for the > second