search for: getpreferredalignmentlog

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

Hello everybody, I am somewhat confused by the following method within the LLVM, especially the lines "confusion starts" -> "confusion ends" are hard to follow. 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 boundary. However, my assembler complains here because it only supports 1-, 2-,

...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 (revision...

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

...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 > =================================================================== > --- inc...

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

...RegisterInfo::getFrameIndexOffset(llvm::MachineFunction const&, int) const", referenced from: vtable for llvm::EBCRegisterInfoin libLLVMEBCCodeGen.a(EBCRegisterInfo.cpp.o) vtable for llvm::EBCGenRegisterInfoin libLLVMEBCCodeGen.a(EBCRegisterInfo.cpp.o) "llvm::TargetData::getPreferredAlignmentLog(llvm::GlobalVariable const*) const", referenced from: getGVAlignmentLog2(llvm::GlobalValue const*, llvm::TargetData const&, unsigned int)in libLLVMAsmPrinter.a(AsmPrinter.cpp.o) "llvm::TargetMachine::~TargetMachine()", referenced from: llvm::LLVMTargetMachine::~LLVM...