[llvm-commits] llvm-gcc: better support for variable size struct fields

Devang Patel dpatel at apple.com
Mon Mar 19 13:55:48 PDT 2007


On Mar 6, 2007, at 8:25 AM, Duncan Sands wrote:

> This patch applies on top of the previously posted patch
> "llvm-gcc: use component_ref_field_offset in component references",
> http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070226/045399.html 
> .
>
> This fixes wrong handling of structs containing more than one
> variable sized field.  Two C testcases are attached.  Consider
> for example the struct from VarSizeInStruct1:
>   struct f { char w; char x[n]; char z[]; };
> DecodeStructFields does the following: it creates a field for
> w; it skips x; it doesn't skip z because it is the last field,
> however it thinks it starts at byte offset 0 because it starts
> at the variable offset n+1, and so pops w out of the struct
> and replaces it with z, leading to the LLVM struct { [0 * i8] }.
> This causes an assertion failure later on in EmitLV_COMPONENT_REF.
> The other testcase is similar, and leads to a different assertion
> failure.
>
> I first prepared a minimal fix, but later noticed that the code for
> handling variable sized struct fields was unnecessarily complicated
> and came up with this more involved patch, which removes a bunch of
> special casing.  The existing code seems rather fixated on whether
> TYPE_SIZE is constant or not, when what really matters is whether the
> field starts at a constant offset.  I simply skip over fields if and
> only if they don't start at a constant offset, and let variable sized
> fields be emitted and indexed like any others (no more ~0U field  
> indices).
> I remove the special casing for ~0U field indices everywhere in favour
> of the generic code, for example in EmitLV_COMPONENT_REF.  The only
> place where something still needs to be done is in  
> ConvertRecordCONSTRUCTOR,
> but there too the code simplifies.
>
> I see no additional failures in the regression test suite or in
> MultiSource with these changes.

Applied.
-
Devang



More information about the llvm-commits mailing list