[LLVMdev] Two new 'llvmnotes'

Duncan Sands baldrick at free.fr
Mon May 5 02:02:59 PDT 2008


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.

Also, there are an infinite number of different ways of
returning void: return {} or {{}} or {{{}}} etc, not
to mention returning zero length arrays.  I guess that's
life.

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

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.

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)?

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

Ciao,

Duncan.



More information about the llvm-dev mailing list