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/bad-tls-fold.mir

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

78 lines
1.9 KiB
Plaintext
Raw Normal View History

[x86] Fix nasty bug in the x86 backend that is essentially impossible to hit from IR but creates a minefield for MI passes. The x86 backend has fairly powerful logic to try and fold loads that feed register operands to instructions into a memory operand on the instruction. This is almost always a good thing, but there are specific relocated loads that are only allowed to appear in specific instructions. Notably, R_X86_64_GOTTPOFF is only allowed in `movq` and `addq`. This patch blocks folding of memory operands using this relocation unless the target is in fact `addq`. The particular relocation indicates why we simply don't hit this under normal circumstances. This relocation is only used for TLS, and it gets used in very specific ways in conjunction with %fs-relative addressing. The result is that loads using this relocation are essentially never eligible for folding into an instruction's memory operands. Unless, of course, you have an MI pass that inserts usage of such a load. I have exactly such an MI pass and was greeted by truly mysterious miscompiles where the linker replaced my instruction with a completely garbage byte sequence. Go team. This is the only such relocation I'm aware of in x86, but there may be others that need to be similarly restricted. Fixes PR36165. Differential Revision: https://reviews.llvm.org/D42732 llvm-svn: 324546
2018-02-08 07:59:14 +08:00
# RUN: llc -x mir < %s | FileCheck %s
--- |
target triple = "x86_64-unknown-linux-gnu"
@x = external global i64
@i = external thread_local global i32
define i32 @or() {
entry:
ret i32 undef
}
define i32 @and() {
entry:
ret i32 undef
}
...
---
# CHECK-LABEL: or:
name: or
[Alignment] Use llvm::Align in MachineFunction and TargetLowering - fixes mir parsing Summary: This catches malformed mir files which specify alignment as log2 instead of pow2. See https://reviews.llvm.org/D65945 for reference, This is patch is part of a series to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html See this patch for the introduction of the type: https://reviews.llvm.org/D64790 Reviewers: courbet Subscribers: MatzeB, qcolombet, dschuff, arsenm, sdardis, nemanjai, jvesely, nhaehnle, hiraditya, kbarton, asb, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, jrtc27, MaskRay, zzheng, edward-jones, atanasyan, rogfer01, MartinMosbeck, brucehoult, the_o, PkmX, jocewei, jsji, Petar.Avramovic, asbirlea, s.egerton, pzheng, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D67433 llvm-svn: 371608
2019-09-11 19:16:48 +08:00
alignment: 16
[x86] Fix nasty bug in the x86 backend that is essentially impossible to hit from IR but creates a minefield for MI passes. The x86 backend has fairly powerful logic to try and fold loads that feed register operands to instructions into a memory operand on the instruction. This is almost always a good thing, but there are specific relocated loads that are only allowed to appear in specific instructions. Notably, R_X86_64_GOTTPOFF is only allowed in `movq` and `addq`. This patch blocks folding of memory operands using this relocation unless the target is in fact `addq`. The particular relocation indicates why we simply don't hit this under normal circumstances. This relocation is only used for TLS, and it gets used in very specific ways in conjunction with %fs-relative addressing. The result is that loads using this relocation are essentially never eligible for folding into an instruction's memory operands. Unless, of course, you have an MI pass that inserts usage of such a load. I have exactly such an MI pass and was greeted by truly mysterious miscompiles where the linker replaced my instruction with a completely garbage byte sequence. Go team. This is the only such relocation I'm aware of in x86, but there may be others that need to be similarly restricted. Fixes PR36165. Differential Revision: https://reviews.llvm.org/D42732 llvm-svn: 324546
2018-02-08 07:59:14 +08:00
tracksRegLiveness: true
registers:
- { id: 0, class: gr64 }
- { id: 1, class: gr64 }
- { id: 2, class: gr64 }
- { id: 3, class: gr64 }
- { id: 4, class: gr32 }
body: |
bb.0.entry:
%0:gr64 = MOV64rm $rip, 1, $noreg, @x, $noreg :: (load 8)
%1:gr64 = OR64ri8 %0, 7, implicit-def dead $eflags
%2:gr64 = MOV64rm $rip, 1, $noreg, target-flags(x86-gottpoff) @i, $noreg :: (load 8)
%3:gr64 = OR64rr %2, %1, implicit-def dead $eflags
%4:gr32 = MOV32rm killed %3, 1, $noreg, 0, $fs :: (load 4)
; CHECK-NOT: orq {{.*}}GOTTPOFF{{.*}}
;
; What we actually expect:
; CHECK: movq {{.*}}GOTTPOFF{{.*}}, %[[R:.*]]
; CHECK-NEXT: orq %{{.*}}, %[[R]]
; CHECK-NEXT: movl %fs:(%[[R]]),
;
; CHECK-NOT: orq {{.*}}GOTTPOFF{{.*}}
$eax = COPY %4
RET 0, $eax
...
---
# CHECK-LABEL: and:
name: and
[Alignment] Use llvm::Align in MachineFunction and TargetLowering - fixes mir parsing Summary: This catches malformed mir files which specify alignment as log2 instead of pow2. See https://reviews.llvm.org/D65945 for reference, This is patch is part of a series to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html See this patch for the introduction of the type: https://reviews.llvm.org/D64790 Reviewers: courbet Subscribers: MatzeB, qcolombet, dschuff, arsenm, sdardis, nemanjai, jvesely, nhaehnle, hiraditya, kbarton, asb, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, jrtc27, MaskRay, zzheng, edward-jones, atanasyan, rogfer01, MartinMosbeck, brucehoult, the_o, PkmX, jocewei, jsji, Petar.Avramovic, asbirlea, s.egerton, pzheng, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D67433 llvm-svn: 371608
2019-09-11 19:16:48 +08:00
alignment: 16
[x86] Fix nasty bug in the x86 backend that is essentially impossible to hit from IR but creates a minefield for MI passes. The x86 backend has fairly powerful logic to try and fold loads that feed register operands to instructions into a memory operand on the instruction. This is almost always a good thing, but there are specific relocated loads that are only allowed to appear in specific instructions. Notably, R_X86_64_GOTTPOFF is only allowed in `movq` and `addq`. This patch blocks folding of memory operands using this relocation unless the target is in fact `addq`. The particular relocation indicates why we simply don't hit this under normal circumstances. This relocation is only used for TLS, and it gets used in very specific ways in conjunction with %fs-relative addressing. The result is that loads using this relocation are essentially never eligible for folding into an instruction's memory operands. Unless, of course, you have an MI pass that inserts usage of such a load. I have exactly such an MI pass and was greeted by truly mysterious miscompiles where the linker replaced my instruction with a completely garbage byte sequence. Go team. This is the only such relocation I'm aware of in x86, but there may be others that need to be similarly restricted. Fixes PR36165. Differential Revision: https://reviews.llvm.org/D42732 llvm-svn: 324546
2018-02-08 07:59:14 +08:00
tracksRegLiveness: true
registers:
- { id: 0, class: gr64 }
- { id: 1, class: gr64 }
- { id: 2, class: gr64 }
- { id: 3, class: gr64 }
- { id: 4, class: gr32 }
body: |
bb.0.entry:
%0:gr64 = MOV64rm $rip, 1, $noreg, @x, $noreg :: (load 8)
%1:gr64 = OR64ri8 %0, 7, implicit-def dead $eflags
%2:gr64 = MOV64rm $rip, 1, $noreg, target-flags(x86-gottpoff) @i, $noreg :: (load 8)
%3:gr64 = AND64rr %2, %1, implicit-def dead $eflags
%4:gr32 = MOV32rm killed %3, 1, $noreg, 0, $fs :: (load 4)
; CHECK-NOT: andq {{.*}}GOTTPOFF{{.*}}
;
; What we actually expect:
; CHECK: movq {{.*}}GOTTPOFF{{.*}}, %[[R:.*]]
; CHECK-NEXT: andq %{{.*}}, %[[R]]
; CHECK-NEXT: movl %fs:(%[[R]]),
;
; CHECK-NOT: andq {{.*}}GOTTPOFF{{.*}}
$eax = COPY %4
RET 0, $eax
...