maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/test/CodeGen/X86/win_cst_pool.ll

103 lines
3.9 KiB
LLVM
Raw Normal View History

[X86] Create mergeable constant pool entries for AVX We supported creating mergeable constant pool entries for smaller constants but not for 32-byte AVX constants. llvm-svn: 261584
2016-02-23 06:23:11 +08:00
; RUN: llc < %s -mtriple=x86_64-win32 -mattr=sse2 -mattr=avx | FileCheck %s
Revert "[COFF] Use comdat shared constants for MinGW as well" This reverts commit r337951. While that kind of shared constant generally works fine in a MinGW setting, it broke some cases of inline assembly that worked before: $ cat const-asm.c int MULH(int a, int b) { int rt, dummy; __asm__ ( "imull %3" :"=d"(rt), "=a"(dummy) :"a"(a), "rm"(b) ); return rt; } int func(int a) { return MULH(a, 1); } $ clang -target x86_64-win32-gnu -c const-asm.c -O2 const-asm.c:4:9: error: invalid variant '00000001' "imull %3" ^ <inline asm>:1:15: note: instantiated into assembly here imull __real@00000001(%rip) ^ A similar error is produced for i686 as well. The same test with a target of x86_64-win32-msvc or i686-win32-msvc works fine. llvm-svn: 338018
2018-07-26 18:48:20 +08:00
; RUN: llc < %s -mtriple=x86_64-win32-gnu -mattr=sse2 -mattr=avx | FileCheck -check-prefix=MINGW %s
CodeGen: Stick constant pool entries in COMDAT sections for WinCOFF COFF lacks a feature that other object file formats support: mergeable sections. To work around this, MSVC sticks constant pool entries in special COMDAT sections so that each constant is in it's own section. This permits unused constants to be dropped and it also allows duplicate constants in different translation units to get merged together. This fixes PR20262. Differential Revision: http://reviews.llvm.org/D4482 llvm-svn: 213006
2014-07-15 06:57:27 +08:00
target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-pc-windows-msvc"
define double @double() {
ret double 0x0000000000800000
}
; CHECK: .globl __real@0000000000800000
MC: Emit COFF section flags in the "proper" order COFF section flags are not idempotent: 'rd' will make a read-write section because 'd' implies write 'dr' will make a read-only section because 'r' disables write llvm-svn: 228490
2015-02-07 16:26:40 +08:00
; CHECK-NEXT: .section .rdata,"dr",discard,__real@0000000000800000
[MC] Use .p2align instead of .align For historic reasons, the behavior of .align differs between targets. Fortunately, there are alternatives, .p2align and .balign, which make the interpretation of the parameter explicit, and which behave consistently across targets. This patch teaches MC to use .p2align instead of .align, so that people reading code for multiple architectures don't have to remember which way each platform does its .align directive. Differential Revision: http://reviews.llvm.org/D16549 llvm-svn: 258750
2016-01-26 08:03:25 +08:00
; CHECK-NEXT: .p2align 3
CodeGen: Stick constant pool entries in COMDAT sections for WinCOFF COFF lacks a feature that other object file formats support: mergeable sections. To work around this, MSVC sticks constant pool entries in special COMDAT sections so that each constant is in it's own section. This permits unused constants to be dropped and it also allows duplicate constants in different translation units to get merged together. This fixes PR20262. Differential Revision: http://reviews.llvm.org/D4482 llvm-svn: 213006
2014-07-15 06:57:27 +08:00
; CHECK-NEXT: __real@0000000000800000:
; CHECK-NEXT: .quad 8388608
; CHECK: double:
; CHECK: movsd __real@0000000000800000(%rip), %xmm0
; CHECK-NEXT: ret
Revert "[COFF] Use comdat shared constants for MinGW as well" This reverts commit r337951. While that kind of shared constant generally works fine in a MinGW setting, it broke some cases of inline assembly that worked before: $ cat const-asm.c int MULH(int a, int b) { int rt, dummy; __asm__ ( "imull %3" :"=d"(rt), "=a"(dummy) :"a"(a), "rm"(b) ); return rt; } int func(int a) { return MULH(a, 1); } $ clang -target x86_64-win32-gnu -c const-asm.c -O2 const-asm.c:4:9: error: invalid variant '00000001' "imull %3" ^ <inline asm>:1:15: note: instantiated into assembly here imull __real@00000001(%rip) ^ A similar error is produced for i686 as well. The same test with a target of x86_64-win32-msvc or i686-win32-msvc works fine. llvm-svn: 338018
2018-07-26 18:48:20 +08:00
; MINGW: .section .rdata,"dr"
; MINGW-NEXT: .p2align 3
; MINGW-NEXT: [[LABEL:\.LC.*]]:
; MINGW-NEXT: .quad 8388608
; MINGW: double:
; MINGW: movsd [[LABEL]](%rip), %xmm0
; MINGW-NEXT: ret
CodeGen: Stick constant pool entries in COMDAT sections for WinCOFF COFF lacks a feature that other object file formats support: mergeable sections. To work around this, MSVC sticks constant pool entries in special COMDAT sections so that each constant is in it's own section. This permits unused constants to be dropped and it also allows duplicate constants in different translation units to get merged together. This fixes PR20262. Differential Revision: http://reviews.llvm.org/D4482 llvm-svn: 213006
2014-07-15 06:57:27 +08:00
define <4 x i32> @vec1() {
ret <4 x i32> <i32 3, i32 2, i32 1, i32 0>
}
; CHECK: .globl __xmm@00000000000000010000000200000003
MC: Emit COFF section flags in the "proper" order COFF section flags are not idempotent: 'rd' will make a read-write section because 'd' implies write 'dr' will make a read-only section because 'r' disables write llvm-svn: 228490
2015-02-07 16:26:40 +08:00
; CHECK-NEXT: .section .rdata,"dr",discard,__xmm@00000000000000010000000200000003
[MC] Use .p2align instead of .align For historic reasons, the behavior of .align differs between targets. Fortunately, there are alternatives, .p2align and .balign, which make the interpretation of the parameter explicit, and which behave consistently across targets. This patch teaches MC to use .p2align instead of .align, so that people reading code for multiple architectures don't have to remember which way each platform does its .align directive. Differential Revision: http://reviews.llvm.org/D16549 llvm-svn: 258750
2016-01-26 08:03:25 +08:00
; CHECK-NEXT: .p2align 4
CodeGen: Stick constant pool entries in COMDAT sections for WinCOFF COFF lacks a feature that other object file formats support: mergeable sections. To work around this, MSVC sticks constant pool entries in special COMDAT sections so that each constant is in it's own section. This permits unused constants to be dropped and it also allows duplicate constants in different translation units to get merged together. This fixes PR20262. Differential Revision: http://reviews.llvm.org/D4482 llvm-svn: 213006
2014-07-15 06:57:27 +08:00
; CHECK-NEXT: __xmm@00000000000000010000000200000003:
; CHECK-NEXT: .long 3
; CHECK-NEXT: .long 2
; CHECK-NEXT: .long 1
; CHECK-NEXT: .long 0
; CHECK: vec1:
; CHECK: movaps __xmm@00000000000000010000000200000003(%rip), %xmm0
; CHECK-NEXT: ret
define <8 x i16> @vec2() {
ret <8 x i16> <i16 7, i16 6, i16 5, i16 4, i16 3, i16 2, i16 1, i16 0>
}
; CHECK: .globl __xmm@00000001000200030004000500060007
MC: Emit COFF section flags in the "proper" order COFF section flags are not idempotent: 'rd' will make a read-write section because 'd' implies write 'dr' will make a read-only section because 'r' disables write llvm-svn: 228490
2015-02-07 16:26:40 +08:00
; CHECK-NEXT: .section .rdata,"dr",discard,__xmm@00000001000200030004000500060007
[MC] Use .p2align instead of .align For historic reasons, the behavior of .align differs between targets. Fortunately, there are alternatives, .p2align and .balign, which make the interpretation of the parameter explicit, and which behave consistently across targets. This patch teaches MC to use .p2align instead of .align, so that people reading code for multiple architectures don't have to remember which way each platform does its .align directive. Differential Revision: http://reviews.llvm.org/D16549 llvm-svn: 258750
2016-01-26 08:03:25 +08:00
; CHECK-NEXT: .p2align 4
CodeGen: Stick constant pool entries in COMDAT sections for WinCOFF COFF lacks a feature that other object file formats support: mergeable sections. To work around this, MSVC sticks constant pool entries in special COMDAT sections so that each constant is in it's own section. This permits unused constants to be dropped and it also allows duplicate constants in different translation units to get merged together. This fixes PR20262. Differential Revision: http://reviews.llvm.org/D4482 llvm-svn: 213006
2014-07-15 06:57:27 +08:00
; CHECK-NEXT: __xmm@00000001000200030004000500060007:
; CHECK-NEXT: .short 7
; CHECK-NEXT: .short 6
; CHECK-NEXT: .short 5
; CHECK-NEXT: .short 4
; CHECK-NEXT: .short 3
; CHECK-NEXT: .short 2
; CHECK-NEXT: .short 1
; CHECK-NEXT: .short 0
; CHECK: vec2:
; CHECK: movaps __xmm@00000001000200030004000500060007(%rip), %xmm0
; CHECK-NEXT: ret
CodeGen: Handle ConstantVector and undef in WinCOFF constant pools The constant pool entry code for WinCOFF assumed that vector constants would be formed using ConstantDataVector, it did not expect to see a ConstantVector. Furthermore, it did not expect undef as one of the elements of the vector. ConstantVectors should be handled like ConstantDataVectors, treat Undef as zero. llvm-svn: 213038
2014-07-15 10:34:12 +08:00
define <4 x float> @undef1() {
ret <4 x float> <float 1.0, float 1.0, float undef, float undef>
; CHECK: .globl __xmm@00000000000000003f8000003f800000
MC: Emit COFF section flags in the "proper" order COFF section flags are not idempotent: 'rd' will make a read-write section because 'd' implies write 'dr' will make a read-only section because 'r' disables write llvm-svn: 228490
2015-02-07 16:26:40 +08:00
; CHECK-NEXT: .section .rdata,"dr",discard,__xmm@00000000000000003f8000003f800000
[MC] Use .p2align instead of .align For historic reasons, the behavior of .align differs between targets. Fortunately, there are alternatives, .p2align and .balign, which make the interpretation of the parameter explicit, and which behave consistently across targets. This patch teaches MC to use .p2align instead of .align, so that people reading code for multiple architectures don't have to remember which way each platform does its .align directive. Differential Revision: http://reviews.llvm.org/D16549 llvm-svn: 258750
2016-01-26 08:03:25 +08:00
; CHECK-NEXT: .p2align 4
CodeGen: Handle ConstantVector and undef in WinCOFF constant pools The constant pool entry code for WinCOFF assumed that vector constants would be formed using ConstantDataVector, it did not expect to see a ConstantVector. Furthermore, it did not expect undef as one of the elements of the vector. ConstantVectors should be handled like ConstantDataVectors, treat Undef as zero. llvm-svn: 213038
2014-07-15 10:34:12 +08:00
; CHECK-NEXT: __xmm@00000000000000003f8000003f800000:
; CHECK-NEXT: .long 1065353216 # float 1
; CHECK-NEXT: .long 1065353216 # float 1
; CHECK-NEXT: .zero 4
; CHECK-NEXT: .zero 4
; CHECK: undef1:
; CHECK: movaps __xmm@00000000000000003f8000003f800000(%rip), %xmm0
; CHECK-NEXT: ret
}
Revert "Revert r240762 "[X86] Cleanup X86WindowsTargetObjectFile::getSectionForConstant"" This reverts commit r240793 while fixing how we handle array constant pool entries. This fixes PR23966. llvm-svn: 240811
2015-06-27 02:55:48 +08:00
define float @pr23966(i32 %a) {
%tobool = icmp ne i32 %a, 0
%sel = select i1 %tobool, float -1.000000e+00, float 1.000000e+00
ret float %sel
}
; CHECK: .globl __real@bf8000003f800000
; CHECK-NEXT: .section .rdata,"dr",discard,__real@bf8000003f800000
[X86] Use the correct alignment for COMDAT constant pool entries COFF doesn't have sections with mergeable contents. Instead, each constant pool entry ends up in a COMDAT section. The linker, when choosing between COMDAT sections, doesn't choose the max alignment of the two sections. You just get whatever alignment was on the section. If one constant needed a higher alignment in one object file from another one, then we will get into trouble if the linker chooses the lower alignment one. Instead, lets promote the alignment of the constant pool entry to make sure we don't use an under aligned constant with an instruction which assumed otherwise. This fixes PR26680. llvm-svn: 261462
2016-02-21 09:30:30 +08:00
; CHECK-NEXT: .p2align 3
Revert "Revert r240762 "[X86] Cleanup X86WindowsTargetObjectFile::getSectionForConstant"" This reverts commit r240793 while fixing how we handle array constant pool entries. This fixes PR23966. llvm-svn: 240811
2015-06-27 02:55:48 +08:00
; CHECK-NEXT: __real@bf8000003f800000:
; CHECK-NEXT: .long 1065353216
; CHECK-NEXT: .long 3212836864
[X86] Create mergeable constant pool entries for AVX We supported creating mergeable constant pool entries for smaller constants but not for 32-byte AVX constants. llvm-svn: 261584
2016-02-23 06:23:11 +08:00
define <4 x i64> @ymm() {
entry:
ret <4 x i64> <i64 8589934593, i64 17179869187, i64 8589934593, i64 17179869187>
}
; CHECK: .globl __ymm@0000000400000003000000020000000100000004000000030000000200000001
; CHECK: .section .rdata,"dr",discard,__ymm@0000000400000003000000020000000100000004000000030000000200000001
; CHECK: .p2align 5
; CHECK: __ymm@0000000400000003000000020000000100000004000000030000000200000001:
; CHECK: .quad 8589934593 # 0x200000001
; CHECK: .quad 17179869187 # 0x400000003
; CHECK: .quad 8589934593 # 0x200000001
; CHECK: .quad 17179869187