llvm dev - Oct 2010 - [LLVMdev] Structure memory layout

Hi renato,

First, I really appreciate your answer. :)

The IR in an previous e-mail is incomplete so far and
I am converting it to various shape.

My team members decided to add new types to solve the bitfield's alignment
problem.

Let's consider your previous examples:

struct testChar { char a:3;  char b:4;  char c:3;  char d:2; };
struct testShort { short a:3;  short b:4;  short c:3;  short d:2; };
struct testInt { int a:3;  int b:4;  int c:3;  int d:2; };

In future, our IRs will be represented as following:

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

This was just concept and I didn't implement it yet.

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

I will report your opinion to my team members and we will discuss that.

Thanks for your answer,
Jin-Gu Kang

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

Hi Renato,

First, I appreciate your answer again. :)
>> %Char = type { c3, c4, c3, c2 }
>> %Short = type { s3, s4, s3, s2 }
>> %Int = type { i3, i4, i3, i2 }
> 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.
I think you misunderstood our type notation.
By using your suggetion, "s4" means "i4 align short" in our
notation.
In "i4 align 2" for "short a:4", I think that "align
2" is already target dependent
because short can be 2 or 4 bytes according to each target.
so I wonder how do you think about "i4 align short" notation.
(Is it impossible to have c specifier in align in order to be consistent with
the rest of LLVM?)

Your answer is so helpful to me. :)

Thanks,
Jin-Gu Kang