search for: getalign

On Mon, 22 May 2017, Dr. ERDI Gergo wrote: > Actually, tracking down the sequence of function calls, it turns out that '8' > is ultimately coming from the following call in DataLayout::getAlignment: > > getAlignmentInfo(AGGREGATE_ALIGN, 0, abi_or_pref, Ty); > > this seems to return 8 with the following datalayout string: > > e-S8:p:16:8-i8:8-i16:8-i32:8-i64:8-f32:8-f64:8-n8-a:8 > > I think my problem is that 'a:8' probably doesn't mean what I think it s...

I'm just diving into LLVM. What does it mean when LoadInst::getAlignment() returns 0? Unknown alignment, use default alignment of the type for the load, something else? In particular, clang appears to set to 0 the alignment of the load instruction that results from accessing the lvalue returned by a call. Is this the intended behavior? For example: const doubl...

In DAGCombiner::MergeConsecutiveStores, there is this check: if (Index->getAlignment() != St->getAlignment()) break; Apparently this check ensures that all of the stores have the same alignment. Why is that necessary? This seems very overly restrictive to me. -David

Hi Dmitry, > I'm attaching a patch 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 pre...

...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 // larger alignment. i...

David, thank you for the prompt response. I originally implemented this with a check of getAlignment(). However, both getAlignment() and getOriginalAlignment() on the <4 x i32> load return the stronger alignment (16) rather than the alignment that the i32* parameter would have (4). So I am a bit stuck in terms of how to verify the original alignment. On Mon, Dec 26, 2016 at 3:26 PM, Da...

...eGen/SelectionDAG/DAGCombiner.cpp (working copy) @@ -4903,9 +4903,9 @@ // resultant store does not need a higher alignment than the original. if (Value.getOpcode() == ISD::BIT_CONVERT && !ST->isTruncatingStore() && 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 &&...

....] // If this is a store of a bit convert, store the input value if the // resultant store does not need a higher alignment 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(IS...

The 8 in the data layout string should have been converted to a byte value by this code before it was passed to setAlignment. As far as I cant ell getAlignment should return the byte alignment that was passed to setAlignment, not the bit alignment from the string. // ABI alignment. if (Rest.empty()) report_fatal_error( "Missing alignment specification in datalayout string"); Split = split(Rest, ':...

...pp +++ 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 ? LI->getAlignment() : SI->getAlignment(); + if (Alignment == 0) + Alignment = 1; unsigned AddressSpace = Ptr->getType()->getPointerAddressSpace(); unsigned ScalarAllocatedSize = DL->getTypeAllocSize(ScalarDataTy); unsigned VectorElementSize = DL->getTypeStoreSize(DataTy)/VF; Should f...

...ment parameters to the getLoad/getExtLoad calls. If you move the handling of Alignment==0 out of ScheduleDAGEmit.cpp and into SelectionDAG::getConstantPool, you can then have legalize read the alignment from the node, instead of making its own decision: cast<ConstantPoolSDNode>(CPIdx)->getAlignment() Dan

...d/getExtLoad calls. > > If you move the handling of Alignment==0 out of ScheduleDAGEmit.cpp > and into SelectionDAG::getConstantPool, you can then have legalize > read the alignment from the node, instead of making its own > decision: > cast<ConstantPoolSDNode>(CPIdx)->getAlignment() > > I followed your suggestion but I've come across a bit of a snag. If you get the alignment in LegalizeDAG using: SDValue CPIdx = DAG.getConstantPool(LLVMC, TLI.getPointerTy()); unsigned Alignment = cast<ConstantPoolSDNode>(CPIdx)->getAlignment(); The ConstantPoolSD...

...id, You are right. This check is overly restrictive. We can replace this check with code that uses the alignment of the first store. Thanks, Nadav On Nov 22, 2013, at 9:31 AM, dag at cray.com wrote: > In DAGCombiner::MergeConsecutiveStores, there is this check: > > if (Index->getAlignment() != St->getAlignment()) > break; > > Apparently this check ensures that all of the stores have the same > alignment. Why is that necessary? This seems very overly restrictive > to me. > > -David > _________________________________...

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.

On 26 Dec 2016, at 15:49, Nemanja Ivanovic <nemanja.i.ibm at gmail.com> wrote: > > David, thank you for the prompt response. > I originally implemented this with a check of getAlignment(). However, both getAlignment() and getOriginalAlignment() on the <4 x i32> load return the stronger alignment (16) rather than the alignment that the i32* parameter would have (4). > > So I am a bit stuck in terms of how to verify the original alignment. It sounds as if the probl...

...preciated. > > 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 &...

...; Hi Dmitry, > > >> I'm attaching a patch 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 &gt...

...at I would like to do is emit efficient code for cases where the parameter pointer has the same alignment requirements as the load and emit the conservative but less efficient code in other cases. Do you actually need to know the original type for this? Isn’t it enough to know the alignment? The getAlignment() / getOriginalAlignment() methods on the LoadSDNode should give you this. David

...right? > @@ -2290,7 +2301,7 @@ Value *TreeToLLVM::EmitLoadOfLValue(tree > LValue LV = EmitLV(exp); > bool isVolatile = TREE_THIS_VOLATILE(exp); > const Type *Ty = ConvertType(TREE_TYPE(exp)); > - unsigned Alignment = expr_align(exp) / 8; > + unsigned Alignment = LV.getAlignment(); Here expr_align(exp) is correct I think. > @@ -2963,7 +2974,7 @@ Value *TreeToLLVM::EmitMODIFY_EXPR(tree > > LValue LV = EmitLV(lhs); > bool isVolatile = TREE_THIS_VOLATILE(lhs); > - unsigned Alignment = expr_align(lhs) / 8; > + unsigned Alignment = LV.getAlign...

.../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 ? 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). -H...