[LLVMdev] Two new 'llvmnotes'

[Chris Lattner]

On May 5, 2008, at 2:02 AM, Duncan Sands wrote:

> Hi Chris,
>
>> Eliminating the 'Void' Type:
>> http://nondot.org/sabre/LLVMNotes/EliminatingVoid.txt
>
> might not some ABI's require some special stuff when
> returning a struct, regardless of whether the struct
> is empty or not?  If so this might add a cost if you
> use {} for void.

Sure, in which case they'd need to use some special attribute, or use  
stret for the struct return case.  This is no different than today.

>> Aggregates as First Class Values:
>> http://nondot.org/sabre/LLVMNotes/FirstClassAggregates.txt
>
> Does this mean that vector types can be removed in favour
> of ordinary arrays?

Not as a first step, but probably as a second step.  For the first  
step, I don't want to allow arithmetic on aggregate values.  We can  
generalize this after the basics are in place.

> If not, maybe at least vectors should
> be changed to derive from array types, and no longer be
> primitive types.  This would make it easier to fix a bunch
> of problems with vector types, for example that the primitive
> size of <4 x i1> is 4 bits but in fact it's codegened like
> [4 x i1], which takes up 4 bytes.  It might also reduce the
> amount of special vector code.

Array and Vector types share a common base class (SequentialType).  I  
agree that simplifying layout would be a big benefit.

> Your plan means that you can have loads and stores where
> you don't know the size of the value being loaded/stored
> (unless you have target data).  I don't know if it matters.

I'm not sure what you mean.  Isn't this the same as loading a pointer  
(whose size depends on TD)?

> You say "I suggest that aggregates be passed just like 'byval'
> arguments by default".  Wouldn't it make more sense to pass
> in registers (or stack elements if you run out of registers)?

an aggregate with the 'inreg' attribute could be passed that way.

> Note that MVT::ValueType is no longer adequate once you have
> structs and arrays.

In the codegen, they are always lowered to their elements by SDISel,  
so they don't make it into the dag.  This code is already almost all  
in place.

-Chris