search for: getpreftypealignment

Hi, I'm seeing a bug in the AVR backend that seems to be caused by LLVM thinking things will be aligned to 8 bytes whereas they are unaligned. Specifically, MF->getDataLayout().getPrefTypeAlignment(Ty) returns 8 for the following two types: %opt = type { i8, [0 x i8], [3 x i8] } %Machine = type { i16, [0 x i8], i16, [0 x i8], [16 x i8], [0 x i8] } The target datalayout specifies that pointers are aligned to 8 bits (i.e. unaligned), so I would expect getPrefTypeAlignment to return 1: targ...

...re a few mid-level optimizers that make use of the preferred alignment. In particular: * lib/Analysis/ValueTracking.cpp - uses getPreferredAlignment() to determine number of trailing zeros of the address of a global defined in the current module. * lib/Transforms/Utils/InlineFunction.cpp - Uses getPrefTypeAlignment() to set the alignment of the alloca it introduces when a byval argument is inlined * lib/Transforms/IPO/ConstantMerge.cpp - Uses getPreferredAlignment() to determine the alignment of the merged constant. * lib/Transforms/Vectorize/BBVectorize.cpp - Depending on what options are set this pass a...

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: "Arnold Schwaighofer" <aschwaighofer at apple.com> >> To: "Joshua Klontz" <josh....

...h that should fix the issue mentioned above. It > simply makes the same check seen in the same file for global > variables: > > emitPTXAddressSpace(PTy->getAddressSpace(), O); > if (GVar->getAlignment() == 0) > O << " .align " << (int) TD->getPrefTypeAlignment(ETy); > else > O << " .align " << GVar->getAlignment(); it's not quite the same because your patch uses the ABI alignment, while in this snippet it is the preferred alignment (which is usually the same as the ABI alignment, but may be bigger). > Could...

...n, the doxygen docu is not very helpful here, too. So, any help on this issue is highly appreciated. Thanks in advance! Ciao, Fabian unsigned TargetData::getPreferredAlignment(const GlobalVariable *GV) const { const Type *ElemType = GV->getType()->getElementType(); unsigned Alignment = getPrefTypeAlignment(ElemType); if (GV->getAlignment() > Alignment) Alignment = GV->getAlignment(); ==================== confusion starts ======================== if (GV->hasInitializer()) { if (Alignment < 16) { // If the global is not external, see if it is large. If so, give it a...

...gt; unsigned Alignment = LI ? LI->getAlignment() : SI->getAlignment(); > + if (Alignment == 0) > + Alignment = 1; That may be conservatively correct, but I don't think it is really right. An alignment of 0 is supposed to mean the platform default alignment (IIRC, DataLayout::getPrefTypeAlignment tells you what it is). -Hal > unsigned AddressSpace = Ptr->getType()->getPointerAddressSpace(); > unsigned ScalarAllocatedSize = DL->getTypeAllocSize(ScalarDataTy); > unsigned VectorElementSize = DL->getTypeStoreSize(DataTy)/VF; > > Should fix this. > &gt...

On Mon, 22 May 2017, Krzysztof Parzyszek via llvm-dev wrote: > Probably from LargeArrayMinWidth/LargeArrayAlign settings in Targets.cpp (in > clang). Wait what? In clang? But my input is already LLVM IR. MF->getDataLayout().getPrefTypeAlignment(Ty) must be basing its answer on either something in the IR file, or in the target implementation, but clang is not really in the picture.

...und it. In InstCombiner::ComputeMaskedBits we have the following lines: if (GlobalValue *GV = dyn_cast<GlobalValue>(V)) { unsigned Align = GV->getAlignment(); if (Align == 0 && TD && GV->getType()->getElementType()->isSized()) Align = TD->getPrefTypeAlignment(GV->getType()->getElementType()); It assumes that global values are always optimally aligned. I think this is incorrect and the bottom two lines should be removed. However, I do think it's useful to specify the alignment at the time of GlobalValue creation, so I propose to add a c...

Hi Nicolas, > if (GlobalValue *GV = dyn_cast<GlobalValue>(V)) { > > unsigned Align = GV->getAlignment(); > > if (Align == 0 && TD && GV->getType()->getElementType()->isSized()) > > Align = TD->getPrefTypeAlignment(GV->getType()->getElementType()); > > It assumes that global values are always optimally aligned. I think this is > incorrect and the bottom two lines should be removed. I don't understand - if Align is zero it means that GV was marked as having preferred alignment (that's w...

...e. This "works", but isn't safe. It is relying on an assumption that the backend will provide at least that alignment for a global, and assuming that nothing later than it will change the alignment to 1. This needs to be fixed. > * lib/Transforms/Utils/InlineFunction.cpp - Uses getPrefTypeAlignment() to set the alignment of the alloca it introduces when a byval argument is inlined > * lib/Transforms/IPO/ConstantMerge.cpp - Uses getPreferredAlignment() to determine the alignment of the merged constant. Can't these just leave the alignment unset and let the code generator do its thing?...

...here, too. So, any help on this issue is highly appreciated. > > Thanks in advance! > > Ciao, Fabian > > unsigned TargetData::getPreferredAlignment(const GlobalVariable *GV) const { > const Type *ElemType = GV->getType()->getElementType(); > unsigned Alignment = getPrefTypeAlignment(ElemType); > if (GV->getAlignment()> Alignment) > Alignment = GV->getAlignment(); > > ==================== confusion starts ======================== > if (GV->hasInitializer()) { > if (Alignment< 16) { > // If the global is not external,...

...oned above. It >> >> simply makes the same check seen in the same file for global >> variables: >> >> emitPTXAddressSpace(PTy->getAddressSpace(), O); >> if (GVar->getAlignment() == 0) >> O << " .align " << (int) TD->getPrefTypeAlignment(ETy); >> else >> O << " .align " << GVar->getAlignment(); > > > it's not quite the same because your patch uses the ABI alignment, while > in this snippet it is the preferred alignment (which is usually the same > as the ABI alignment,...

...n't safe. It is relying on an assumption that > the backend will provide at least that alignment for a global, and > assuming that nothing later than it will change the alignment to 1. > This needs to be fixed. > > > * lib/Transforms/Utils/InlineFunction.cpp - Uses > > getPrefTypeAlignment() to set the alignment of the alloca it > > introduces when a byval argument is inlined > > * lib/Transforms/IPO/ConstantMerge.cpp - Uses > > getPreferredAlignment() to determine the alignment of the merged > > constant. > > Can't these just leave the alignment un...

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 ?

Hi all, The InstructionCombining pass causes alignment of globals to be ignored. I've attached a replacement of Fibonacci.cpp which reproduces this (I used 2.3 release). Here's the x86 code it produces: 03C20019 movaps xmm0,xmmword ptr ds:[164E799h] 03C20020 mulps xmm0,xmmword ptr ds:[164E79Ah] 03C20027 movaps xmmword ptr ds:[164E799h],xmm0 03C2002E

On Sep 7, 2012, at 8:02 AM, Richard Osborne <richard at xmos.com> wrote: >>> I was a bit surprised to see these numbers hardcoded in TargetData since everything else is taken from the datalayout string. I was wondering what the logic was behind the number 16. Would it make sense to derive this number from the other alignments somehow (e.g. the maximum preferred alignment across all

...;>> simply makes the same check seen in the same file for global >>> variables: >>> >>> emitPTXAddressSpace(PTy->getAddressSpace(), O); >>> if (GVar->getAlignment() == 0) >>> O << " .align " << (int) TD->getPrefTypeAlignment(ETy); >>> else >>> O << " .align " << GVar->getAlignment(); >> >> >> it's not quite the same because your patch uses the ABI alignment, while >> in this snippet it is the preferred alignment (which is usually the same...

On 06/09/12 20:24, Chris Lattner wrote: > On Sep 6, 2012, at 8:51 AM, Richard Osborne <richard at xmos.com> wrote: > >> I recently noticed that all globals bigger than 16 bytes are being 16 byte aligned by LLVM (assuming there isn't an explicitly requested alignment). I'd really rather avoid this, at least for the XCore backend. I tracked this down to the following code

What exactly is your alignment settings in your LLVM struct? Something like this would tell you the alignment of "something". const llvm::DataLayout dl(theModule); size_t size = dl.getPrefTypeAlignment(something); IIn "my" compiler, I don't do anything special to align structs, so it's plausibly your specific data-layout that says that i64 only needs aligning to 32-bits (and clang adjusts it because "it can", by adding extra padding elements) - or you're using diff...

...the same check seen in the same file for global >>>> variables: >>>> >>>> emitPTXAddressSpace(PTy->**getAddressSpace(), O); >>>> if (GVar->getAlignment() == 0) >>>> O << " .align " << (int) TD->getPrefTypeAlignment(ETy); >>>> else >>>> O << " .align " << GVar->getAlignment(); >>>> >>> >>> >>> it's not quite the same because your patch uses the ABI alignment, while >>> in this snippet it is the prefer...