Garrison Venn
2010-Feb-01 19:06 UTC
[LLVMdev] Equivalent alignment of __attribute__((__aligned__))
Is there a way using llvm::TargetData to determine the alignment of what would be equivalent to __attribute__((__aligned__))? I'm looking for something like a max alignment number for the target platform so that I know what the max alignment of an address returned by malloc(...) will be. Thanks in advance Garrison
Chris Lattner
2010-Feb-01 19:09 UTC
[LLVMdev] Equivalent alignment of __attribute__((__aligned__))
On Feb 1, 2010, at 11:06 AM, Garrison Venn wrote:> Is there a way using llvm::TargetData to determine the alignment of what would be equivalent > to __attribute__((__aligned__))? I'm looking for something like a max alignment number for the > target platform so that I know what the max alignment of an address returned by malloc(...) will > be.Not currently. The alignment implied by attribute(aligned) is probably not something that TargetData should have, but I think it *does* make sense to have the minimal guaranteed alignment of malloc. -Chris
Török Edwin
2010-Feb-01 19:20 UTC
[LLVMdev] Equivalent alignment of __attribute__((__aligned__))
On 02/01/2010 09:06 PM, Garrison Venn wrote:> Is there a way using llvm::TargetData to determine the alignment of what would be equivalent > to __attribute__((__aligned__))? I'm looking for something like a max alignment number for the > target platform so that I know what the max alignment of an address returned by malloc(...) will > be. > >malloc() doesn't have anything to do with attribute(aligned). You can request objects allocated on the stack (with attrib aligned) with alignment greater than what malloc could give you. AFAIK the alignment of malloc() is guaranteed be to at least the alignment of a long double (since that is the C type with the largest alignment requirement). I don't know what guarantees malloc() has regarding vector types, I guess none, it just happens to work because malloc() returns data aligned to 16 bytes. IIRC if you run the program under valgrind for example it would only give you sizeof(void*) alignment. You can find out the minimum ABI alignment for a particular type using TD->getABITypeAlignment(Ty) though. Best regards, --Edwin
Garrison Venn
2010-Feb-01 20:01 UTC
[LLVMdev] Equivalent alignment of __attribute__((__aligned__))
Sorry as you interpreted I meant minimum alignment. My issue is in translating from a C struct which has a member aligned with __attribute__((__aligned__)) to a generated packed StructType where I use padding to force the alignment of said member. Instances of this struct are placed on the heap via malloc. Although I'm currently using static C code to determine the padding size, I'm trying to avoid using such code since I'm not sure which llvm platforms don't support __attribute__((__aligned__)). Knowing that malloc will give me an address aligned to any platform supported datatype, and knowing this minimum alignment (which I believe is equivalent to __attribute__((__aligned__))), I could calculate the above value. I'm currently using the alignment of long double instead. Any recommended way of determining this value or doing the equivalent? Garrison On Feb 1, 2010, at 14:09, Chris Lattner wrote:> > On Feb 1, 2010, at 11:06 AM, Garrison Venn wrote: > >> Is there a way using llvm::TargetData to determine the alignment of what would be equivalent >> to __attribute__((__aligned__))? I'm looking for something like a max alignment number for the >> target platform so that I know what the max alignment of an address returned by malloc(...) will >> be. > > Not currently. The alignment implied by attribute(aligned) is probably not something that TargetData should have, but I think it *does* make sense to have the minimal guaranteed alignment of malloc. > > -Chris
Maybe Matching Threads
- [LLVMdev] Equivalent alignment of __attribute__((__aligned__))
- [LLVMdev] Equivalent alignment of __attribute__((__aligned__))
- [LLVMdev] Equivalent alignment of __attribute__((__aligned__))
- [LLVMdev] Possible DAGCombiner or TargetData Bug
- [LLVMdev] Documentation of malloc/free