mirror of
https://github.com/c64scene-ar/llvm-6502.git
synced 2024-07-17 20:29:31 +00:00
a0fcc08e65
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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@51928 91177308-0d34-0410-b5e6-96231b3b80d8
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
|
|
}
|