[LLVMdev] structs get decomposed when shouldn't

Juhasz David juhda at inf.elte.hu
Tue May 1 13:01:57 PDT 2012


Hi all,

I'm new on the list, so I want to say hello for everybody!

I'm from Hungary and writing a LLVM backend for Tile64 processor as my
master's thesis. It's a big time pressure on me, so the thesis will
probably describe a backend only providing an assembly printer, but the
development is likely to be continued beyond the thesis.

For now, I've run into a very annoying problem while implementing the
calling convention of Tilera architecture. The ABI says that a struct
can be passed in registers if it fits in them. Moreover, if a struct
gets passed in registers, it must be stored well aligned, i.e. just
like as it resides in memory. A padding register must be maintained
before a double-word aligned value if needed, and more than one value
can be stored in a single register, e.g. two i16 in a i32 register.

As I can understand, LLVM is trying to decompose datatypes into smaller
components in some circumstances. E.g. decomposing a double into two
i32 argument automatically is very useful for me because the processor
consists of only i32 registers. However, this decomposition is a
nightmare in the case of structs should passed inside registers.
Speaking of function arguments, the problem can be mitigated by using a
pointer tagged with byval attribute and catch such an argument in a
custom CC function. On the other hand, when a function should return a
struct, byval can't be used.

Of course, there is no problem in case sret-demotion taking place,
automatically for too big structs or forced by sret attribute.
However, smaller structs get decomposed by default into component
elements as returned values. I googled the net all the day,
but, unfortunately, can't find a solution.

Is there any way to disable this feature of LLVM and get structures
as they are when returning them?

Besides solutions, any suggestions and ideas are well appreciated :)

All the best,
David



More information about the llvm-dev mailing list