[LLVMdev] Structure memory layout

Renato Golin renato.golin at arm.com
Tue Oct 19 01:03:25 PDT 2010


On 19 October 2010 07:57, Jin Gu Kang <jaykang10 at imrc.kist.re.kr> wrote:
> Frist, I have been implementing common type for struct type on bitcode
> at compilation time using llvm-gcc and then changing common type to target
> specific types at code generation time using llc (reconstruct StructLayout).

Hi Jin,

Apart from bitfields and unions, the struct type is pretty much target
agnostic. What kind of target-specific structure modifications do you
have in mind?


> Second, I have been adding two new intrinsic functions as following.
> 1. "getelement" intrinsic function to load from bitfield of struct type.
> 2. "setelement" intrinsic function to store to bitfied of struct type.

Bitfields and unions can make the IR a big mess. Analysing the memory
layout of the bitfield is not trivial and the low level bit fiddling
you have to do is too big and ugly to be in IR. An instruction that
knows that would be beneficial (for IR's sake). But there are other
issues at hand, like the IR assuming certain casts are valid (ex.
struct { double } -> char[8]) for a memcpy when you could have it
differently for different targets.

There was a discussion a few weeks ago about unions, you should read
it to understand the problems involved.

Bear in mind that whatever change you make in the generic part of the
IR, you have to implement (or find people that will) in *every*
target, otherwise we can never get rid of the old implementation and
yours will not "catch". That's exactly what happened to the previous
union type and will happen again if it's not done all the way through.

cheers,
--renato




More information about the llvm-dev mailing list