mirror of
https://github.com/RPCS3/llvm-mirror.git
synced 2024-11-25 04:02:41 +01:00
5a6c6a92c1
are the same as in unpacked structs, only field positions differ. This only matters for structs containing x86 long double or an apint; it may cause backwards compatibility problems if someone has bitcode containing a packed struct with a field of one of those types. The issue is that only 10 bytes are needed to hold an x86 long double: the store size is 10 bytes, but the ABI size is 12 or 16 bytes (linux/ darwin) which comes from rounding the store size up by the alignment. Because it seemed silly not to pack an x86 long double into 10 bytes in a packed struct, this is what was done. I now think this was a mistake. Reserving the ABI size for an x86 long double field even in a packed struct makes things more uniform: the ABI size is now always used when reserving space for a type. This means that developers are less likely to make mistakes. It also makes life easier for the CBE which otherwise could not represent all LLVM packed structs (PR2402). Front-end people might need to adjust the way they create LLVM structs - see following change to llvm-gcc. llvm-svn: 51928 |
||
---|---|---|
.. | ||
2002-01-31-CallGraph.ll | ||
2002-02-24-InlineBrokePHINodes.ll | ||
2002-03-11-ConstPropCrash.ll | ||
2003-02-19-LoopInfoNestingBug.ll | ||
2004-08-16-PackedConstantInlineStore.ll | ||
2004-08-16-PackedGlobalConstant.ll | ||
2004-08-16-PackedSelect.ll | ||
2004-08-16-PackedSimple.ll | ||
2004-08-20-PackedControlFlow.ll | ||
2006-02-05-PassManager.ll | ||
2007-04-24-eliminate-mostly-empty-blocks.ll | ||
2007-06-05-PassID.ll | ||
2007-06-16-Funcname.ll | ||
2007-06-28-PassManager.ll | ||
2007-09-10-PassManager.ll | ||
2008-02-14-PassManager.ll | ||
2008-03-19-PassManager.ll | ||
2008-06-04-FieldSizeInPacked.ll | ||
dg.exp | ||
invalid-commandline-option.ll |