mirror of
https://github.com/RPCS3/llvm-mirror.git
synced 2024-10-29 23:12:55 +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
15 lines
578 B
LLVM
15 lines
578 B
LLVM
; RUN: llvm-as < %s | opt -instcombine | llvm-dis | grep true
|
|
|
|
target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128"
|
|
target triple = "x86_64-unknown-linux-gnu"
|
|
%packed = type <{ x86_fp80, i8 }>
|
|
%unpacked = type { x86_fp80, i8 }
|
|
|
|
define i1 @q() nounwind {
|
|
entry:
|
|
%char_p = getelementptr %packed* null, i32 0, i32 1 ; <i8*> [#uses=1]
|
|
%char_u = getelementptr %unpacked* null, i32 0, i32 1 ; <i8*> [#uses=1]
|
|
%res = icmp eq i8* %char_p, %char_u ; <i1> [#uses=1]
|
|
ret i1 %res
|
|
}
|