similar to: [LLVMdev] TargetData::getPreferredAlignment(const GlobalVariable *GV) is strange ...

Hi Fabian, > I am somewhat confused by the following method within the LLVM, > especially the lines > "confusion starts" -> "confusion ends" are hard to follow. yes, this seems like a wart. It has been there ever since Chris added the getPreferredAlignmentLog method in commit 25978. Maybe he can comment on whether the code to bump up the alignment for big

On Mar 9, 2011, at 8:40 AM, Duncan Sands wrote: > Hi Fabian, > >> I am somewhat confused by the following method within the LLVM, >> especially the lines >> "confusion starts" -> "confusion ends" are hard to follow. > > yes, this seems like a wart. It has been there ever since Chris added the > getPreferredAlignmentLog method in commit

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 in TargetData.cpp: if (GV->hasInitializer() && GVAlignment == 0) { if (Alignment < 16) { // If the global

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

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 in TargetData.cpp: > > if

On 07/09/12 18:13, Chris Lattner wrote: > 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

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

I got bit by this in LLVM 2.4 DagCombiner.cpp and it's still in trunk: SDValue DAGCombiner::visitSTORE(SDNode *N) { [...] // 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()) {

I agree, that doesn't look right. It looks like this is what was intended: Index: lib/CodeGen/SelectionDAG/DAGCombiner.cpp =================================================================== --- lib/CodeGen/SelectionDAG/DAGCombiner.cpp (revision 65000) +++ lib/CodeGen/SelectionDAG/DAGCombiner.cpp (working copy) @@ -4903,9 +4903,9 @@ // resultant store does not need a higher alignment than

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

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 Wednesday 18 February 2009 21:43, Dan Gohman wrote: > I agree, that doesn't look right. It looks like this > is what was intended: > > Index: lib/CodeGen/SelectionDAG/DAGCombiner.cpp > =================================================================== > --- lib/CodeGen/SelectionDAG/DAGCombiner.cpp (revision 65000) > +++ lib/CodeGen/SelectionDAG/DAGCombiner.cpp

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"

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 ?

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

Hi Eli, Mon Ping, > In ISO/IEC WG14 n1169 on the C extensions to support embedded > processors, any two address spaces must be disjoint, must be > equivalent, or must be nested. Ah, that standard is a lot clearer on this subject than the DSP-C one I read was. > As Eli indicated, the actual relationship is platform specific depending on > what makes the most sense for

Hi I have IR Code like ... @path = private constant [6xi8] c"abcde\00" ... --- Code from Pass --- GlobalVariable * GVPath = .... // contains @path I want to convert "abcde" to StringRef. Can you help me with GlobalVariable API? GlobalVariable::getInitializer() --> Constant* // How to get exact value äbcde from here? ~mahesh -------------- next part --------------

Given an object o of ElemType in an instance of EquivalenceClasses, I need to get a list of all members of the equivalence class that o is in. For various reasons, it is easiest if I could get an EquivalenceClasses::iterator that I can pass to member_begin and member_end. So naturally, I did something like this (pseudo-C++): EquivalenceClasses::iterator i = equiv.findValue(o);

Hi Duncan, You're right, global variables use preferred alignment. And - yes, preferred alignment in this case is bigger: 8 instead of 4. NVIDIA's prop. compiler gives 4. However, since CUDA 5.0 ptx modules are linkable with each other, I think alignments for externally visible functions and data should all follow ABI rules. Is there a guide on making tests? I have ~5 pending patches

Hi all, > If I read the standard correctly, the properties of these address spaces can > be fully captured by defining the relationship between every pair of address > spaces (disjoint, identical, subset/superset). > > I think it would make sense to make these relationships backend/platform > specific, but for clang and the optimization passes to properly work with > address