search for: structtypeconversioninfo

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...