llvm dev - May 2008 - [LLVMdev] How to handle size_t in front ends?

Gordon Henriksen wrote:
> On 2008-05-21, at 22:17, Talin wrote:
>   
>> As I understand this, this issue and others like it all require a
>> difficult step to be taken, which is to introduce the concept of a
>> constant whose value is not known until code generation time or at  
>> least
>> until the compilation target is fully known. These "late bound
>> constants" could then be used to implement
"sizeof(type)" and other
>> constants whose value is different on different targets.
>>     
>
> LLVM already does this.
>
>
http://www.nondot.org/sabre/LLVMNotes/SizeOf-OffsetOf-VariableSizedStructs.txt
>
> — Gordon
>   
Is there a similar technique that would allow calculation of the 
alignment? (which is also required by the DWARF derived-type descriptor.)

-- Talin

On May 22, 2008, at 6:40 PM, Talin wrote:
>> LLVM already does this.
>>
>>
http://www.nondot.org/sabre/LLVMNotes/SizeOf-OffsetOf-VariableSizedStructs.txt
>>
>> — Gordon
>>
> Is there a similar technique that would allow calculation of the
> alignment? (which is also required by the DWARF derived-type  
> descriptor.)
There is more than one form of alignment.  To find the struct field  
alignment of something, you can do something like:

"sizeof({i8, T}) - sizeof(T)"

-Chris

Chris Lattner wrote:
> On May 22, 2008, at 6:40 PM, Talin wrote:
>   
>>> LLVM already does this.
>>>
>>>
http://www.nondot.org/sabre/LLVMNotes/SizeOf-OffsetOf-VariableSizedStructs.txt
>>>
>>> — Gordon
>>>
>>>       
>> Is there a similar technique that would allow calculation of the
>> alignment? (which is also required by the DWARF derived-type  
>> descriptor.)
>>     
>
> There is more than one form of alignment.  To find the struct field  
> alignment of something, you can do something like:
>
> "sizeof({i8, T}) - sizeof(T)"
>   
Clever. I'll use that.

However, I feel that when a "trick" like this gets used enough times, 
that's a signal that it should be codified. Making sizeof() and 
alignmentof() first-class operations in the IR would have the advantage 
of making the generated IR clearer; And we already know that it can be 
done because the tricks exist.

A lot of this thinking comes out of my attempting to create (as I 
mentioned on the other thread) a generic "DebugBuilder", similar to 
IRBuilder, that pumps out source level debugging definitions. As much as 
possible, I want to hide details of the target machine from the user of 
the API. You ought to be able to hand it an LLVM type, plus a little 
sprinkling of source-derived metadata to go along with it, and it 
figures out all the metrics for you.

This is separate from the issue of size_t, which I realize is much more 
complex because it's not merely a machine-dependent constant, it's a 
machine-dependent *type*. And unlike constants, types cannot be the 
product of an expression in LLVM, so there's no handy trick that can be 
used.

-- Talin