[cfe-commits] r46859 - in /cfe/trunk: CodeGen/CGExpr.cpp CodeGen/CodeGenTypes.cpp test/CodeGen/bitfield.c

[Duncan Sands]

Hi Chris,

> I think we also need alignment info in there, Duncan did you recently  
> run into this in llvm-gcc?

I think we need alignment info in LValue's, at least for bitfields: currently
we extract alignment from the gcc expression, which may not have any relationship
to how we have chosen to address the bitfield (and seems to give the wrong thing
for bitfields anyway, at least when using expr_align).  By noting the alignment
at the same time as we create the addressing info, i.e. when making the Lvalue,
such problems are avoided and the logic is concentrated in one place.  We don't
need to add any of the info that Lauro mentions because we already have it in the
gcc field declaration (which also contains alignment info; this info is probably
more useful than the expr_align result).

Ciao,

Duncan.

> On Feb 8, 2008, at 7:15 PM, Eli Friedman wrote:
> 
> > On Feb 8, 2008 12:02 PM, Lauro Ramos Venancio <lauro.venancio at gmail.com 
> > > wrote:
> >> Nowadays, I think we should change the placeBitfield function
> >> (CodeGenType.cpp) to provide more information making easier to
> >> implement bitfield initializer.
> >
> > Okay.  Ideally, what I would need is, for every declared field in a
> > bitfield, something like the following:
> >
> > struct BitFieldPiece {
> >  unsigned LLVMFieldNo;
> >  unsigned StartBit;
> >  unsigned EndBit;
> > }
> > typedef std::vector<BitFieldPiece> BitFieldLayoutData;
> >
> > This data makes the initializers relatively easy to implement, and
> > avoids any dependency on platform-specific bitfield layout rules, no
> > matter how strange they are. (I don't know how strange the rules can
> > get, though, so I'm not sure if this much generality is needed.)
> >
> > -Eli
> > _______________________________________________
> > cfe-commits mailing list
> > cfe-commits at cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
> 
>