search for: getpreferredalignment

...an a 4 bytes - it just wastes space. I'll try to put together a proposal for making it possible to set this per target. > Ok, after considering this a bit more, how about we take a different approach: despite its name, TargetData is really mostly for consumption by the mid-level optimizers. getPreferredAlignment is really something that only TargetLowering[ObjectFile] should be using. What do you think about sinking getPreferredAlignment down to it? This will make it much easier to target-hookize this. > > -Chris Hi Chris, Sorry for not replying sooner but I've haven't had a chance to look...

...mbler complains here because it only supports 1-, 2-, 4- and 8-byte boundaries :-( I checked the svn log but I didn't find any explanation, 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 ========================...

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 objects is still needed. Ciao, Duncan. Maybe the > idea is that if there > are such big data structures one does not waste much memory anyway if > they are aligned > to a 16-byte...

...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 objects is still needed. Ah, I really vaguely remember this. IIRC, there was some fortran benchmark (that was running through f2c) which had a large array of doubles. On X86, double is only...

...e than a 4 bytes - it just wastes space. I'll try to put together a proposal for making it possible to set this per target. Ok, after considering this a bit more, how about we take a different approach: despite its name, TargetData is really mostly for consumption by the mid-level optimizers. getPreferredAlignment is really something that only TargetLowering[ObjectFile] should be using. What do you think about sinking getPreferredAlignment down to it? This will make it much easier to target-hookize this. -Chris

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

...4 bytes - it just wastes space. I'll try to put together a proposal for making it possible to set this per target. >> Ok, after considering this a bit more, how about we take a different approach: despite its name, TargetData is really mostly for consumption by the mid-level optimizers. getPreferredAlignment is really something that only TargetLowering[ObjectFile] should be using. What do you think about sinking getPreferredAlignment down to it? This will make it much easier to target-hookize this. >> >> -Chris > Hi Chris, > > Sorry for not replying sooner but I've haven'...

...proposal for making it possible > >>> to set this per target. > >> Ok, after considering this a bit more, how about we take a > >> different approach: despite its name, TargetData is really mostly > >> for consumption by the mid-level optimizers. > >> getPreferredAlignment is really something that only > >> TargetLowering[ObjectFile] should be using. What do you think > >> about sinking getPreferredAlignment down to it? This will make it > >> much easier to target-hookize this. > >> > >> -Chris > > Hi Chris, > &...

...a::TargetData(const Module *M) - : ImmutablePass((intptr_t)&ID) { +TargetData::TargetData(const Module *M, const AddrspacesDescriptor &Addrspaces) + : ImmutablePass((intptr_t)&ID), Addrspaces(Addrspaces) { init(M->getDataLayout()); } @@ -604,3 +604,5 @@ unsigned TargetData::getPreferredAlignmentLog(const GlobalVariable *GV) const { return Log2_32(getPreferredAlignment(GV)); } + +const AddrspacesDescriptor TargetData::DefaultAddrspaces; Index: include/llvm/Target/TargetData.h =================================================================== --- include/llvm/Target/TargetData.h (revisi...

...ImmutablePass((intptr_t)&ID) { > +TargetData::TargetData(const Module *M, const AddrspacesDescriptor > &Addrspaces) > + : ImmutablePass((intptr_t)&ID), Addrspaces(Addrspaces) { > init(M->getDataLayout()); > } > > @@ -604,3 +604,5 @@ > unsigned TargetData::getPreferredAlignmentLog(const GlobalVariable > *GV) const { > return Log2_32(getPreferredAlignment(GV)); > } > + > +const AddrspacesDescriptor TargetData::DefaultAddrspaces; > Index: include/llvm/Target/TargetData.h > =================================================================== > ---...

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

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. As Eli indicated, the actual relationship is platform specific depending on what makes the most sense for your hardware and how the program will behave will depend on that relationship. -- Mon Ping On Jul 17, 2008, at 7:25 AM, Eli

...smPrinter::EmitGlobalVariable(llvm::GlobalVariable const*)in libLLVMAsmPrinter.a(AsmPrinter.cpp.o) llvm::TargetLoweringObjectFile::SectionForGlobal(llvm::GlobalValue const*, llvm::Mangler*, llvm::TargetMachine const&) constin libLLVMAsmPrinter.a(AsmPrinter.cpp.o) "llvm::TargetData::getPreferredAlignment(llvm::GlobalVariable const*) const", referenced from: llvm::SelectionDAG::InferPtrAlignment(llvm::SDValue) constin libLLVMSelectionDAG.a(SelectionDAG.cpp.o) llvm::TargetLoweringObjectFileMachO::SelectSectionForGlobal(llvm::GlobalValue const*, llvm::SectionKind, llvm::Mangler*, llvm::Tar...