Displaying 13 results from an estimated 13 matches for "getpreferredalign".
2012 Sep 18
2
[LLVMdev] Preferred alignment of globals > 16bytes
...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 l...
2011 Mar 08
2
[LLVMdev] TargetData::getPreferredAlignment(const GlobalVariable *GV) is strange ...
...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 ====================...
2011 Mar 09
0
[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 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-b...
2011 Mar 09
1
[LLVMdev] TargetData::getPreferredAlignment(const GlobalVariable *GV) is strange ...
...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...
2012 Sep 07
0
[LLVMdev] Preferred alignment of globals > 16bytes
...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
2012 Sep 07
2
[LLVMdev] Preferred alignment of globals > 16bytes
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
2012 Sep 20
0
[LLVMdev] Preferred alignment of globals > 16bytes
...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...
2012 Sep 20
0
[LLVMdev] Preferred alignment of globals > 16bytes
...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,
&g...
2008 Jul 21
2
[LLVMdev] Casting between address spaces and address space semantics
...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 (re...
2008 Jul 21
0
[LLVMdev] Casting between address spaces and address space semantics
...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
> ===================================================================
>...
2008 Jul 18
0
[LLVMdev] Casting between address spaces and address space semantics
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
2008 Jul 17
4
[LLVMdev] Casting between address spaces and address space semantics
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
2011 May 06
0
[LLVMdev] Question about linking llvm-mc when porting a new backend
...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:...