Displaying 4 results from an estimated 4 matches for "structtypeconversioninfo".
2008 Feb 12
2
[LLVMdev] an llvm-gcc bug
...factory" StructType::get to think they are
the same.
But, the second field is marked as Padding in the second case but not
the first,
and CopyAggregate does not copy Padding. When the second type
goes through ConvertType, it is converted to the same llvm Type as the
first type,
and the StructTypeConversionInfo info is replaced; later copies of the
first type
then think they don't have to copy the padding, producing wrong code.
I'm inclined to remove skipping the Padding in CopyAggregate; that's
at best an unimportant optimization, and could result in code that's
slower than doing a...
2006 Dec 08
0
[LLVMdev] Proposed: first class packed structures
...nge ABI considerations force a field to be unaligned, not
an attribute at the source level).
Here's an example of #1:
extern struct { int x; int y; int z; } __attribute((packed)) foos;;
This should just be {int,int,int}, not <{int,int,int}>.
The approach I'd like to see is:
StructTypeConversionInfo should have a bool field "Packed" that is
initialized to false.
As fields are added to StructTypeConversionInfo, there are three cases:
1. GCC wants the field to be at an offset equal to where LLVM would
place it. Just add the field.
2. GCC wants to place the field at an offset fur...
2006 Dec 06
3
[LLVMdev] Proposed: first class packed structures
The attached patch (gcc.patch) implements the gcc portion of packed
types. I have only tested this on a few examples, so I may be missing
some type conversions somewhere.
The gcc patch requires llvm_extra.patch, not included in the previous emails.
Andrew
-------------- next part --------------
A non-text attachment was scrubbed...
Name: llvm_extra.patch
Type: text/x-patch
Size: 1677 bytes
2008 Feb 13
0
[LLVMdev] an llvm-gcc bug
...hink they are
> the same.
> But, the second field is marked as Padding in the second case but not
> the first,
> and CopyAggregate does not copy Padding. When the second type
> goes through ConvertType, it is converted to the same llvm Type as the
> first type,
> and the StructTypeConversionInfo info is replaced; later copies of the
> first type
> then think they don't have to copy the padding, producing wrong code.
there's some mucking around with padding in ConvertUNION presumably
because someone noticed a problem of this kind there.
> I'm inclined to remove skip...