[LLVMdev] Structure memory layout

[Renato Golin]

On 20 October 2010 06:22, Jin Gu Kang <jaykang10 at imrc.kist.re.kr> wrote:
> The IR in an previous e-mail is incomplete so far and
> I am converting it to various shape.

Hi Jin,

No worries. I'm interested in the outcome, so I'm playing the devil's
advocate to make sure your proposal is consistent with the rest of
LLVM.


> %Char = type { c3, c4, c3, c2 }
> %Short = type { s3, s4, s3, s2 }
> %Int = type { i3, i4, i3, i2 }

Ah, this is precisely what the IR cannot do. :(

See, i is not for int (the C data type) but for every integer type on
any language/platform combination. Normally, booleans are i1 and char
i8, in ARM short is 16 and int is 32, and all of them use the 'i'
notation.

So, i3, i4, i5 for bitfields makes sense, but you cannot expect that
s4 = short a:4, because short can be 8 bits or 32 or 17, and this
makes the IR *more* platform-dependent that it already is. The
keywords "Int" and "short" only makes sense at the C level. Lower than
that, everything is a byte/word multiple, and that's platform
dependent.

It is not possible to (ie. nobody will accept that) integer values
have C type specifiers on them, so I wouldn't recommend your team to
do that. Their code simply will not be accepted back, if you care
about it, but more importantly, your IR will be incompatible with
everything else, which is a shame.


> I usually try to modify original llvm system as less as possible,
> so I prefer adding new types to modifying original llvm types.

Contrary to your conclusion, that will eventually trigger all sorts of
changes everywhere. You'll end up with an endless nightmare of changes
throughout the code, IR generation, optimization and codegen, which
could be disastrous.

I still vote for having alignment on types (but maybe because I'm just
not aware of the problems). ;)

-- 
cheers,
--renato