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/ARM/arm-shrink-wrapping.ll

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

1888 lines
61 KiB
LLVM
Raw Normal View History

[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
[ARM] Make the frame lowering code ready for shrink-wrapping. Shrink-wrapping can now be tested on ARM with -enable-shrink-wrap. Related to <rdar://problem/20821730> llvm-svn: 242908
2015-07-23 00:34:37 +08:00
; RUN: llc %s -o - -enable-shrink-wrap=true -ifcvt-fn-start=1 -ifcvt-fn-stop=0 -mtriple=armv7-apple-ios \
[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; RUN: | FileCheck %s --check-prefix=ARM-ENABLE
[ARM] Make the frame lowering code ready for shrink-wrapping. Shrink-wrapping can now be tested on ARM with -enable-shrink-wrap. Related to <rdar://problem/20821730> llvm-svn: 242908
2015-07-23 00:34:37 +08:00
; RUN: llc %s -o - -enable-shrink-wrap=false -ifcvt-fn-start=1 -ifcvt-fn-stop=0 -mtriple=armv7-apple-ios \
[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; RUN: | FileCheck %s --check-prefix=ARM-DISABLE
[ARM] Make the frame lowering code ready for shrink-wrapping. Shrink-wrapping can now be tested on ARM with -enable-shrink-wrap. Related to <rdar://problem/20821730> llvm-svn: 242908
2015-07-23 00:34:37 +08:00
; RUN: llc %s -o - -enable-shrink-wrap=true -ifcvt-fn-start=1 -ifcvt-fn-stop=0 -mtriple=thumbv7-apple-ios \
[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; RUN: | FileCheck %s --check-prefix=THUMB-ENABLE
[ARM] Make the frame lowering code ready for shrink-wrapping. Shrink-wrapping can now be tested on ARM with -enable-shrink-wrap. Related to <rdar://problem/20821730> llvm-svn: 242908
2015-07-23 00:34:37 +08:00
; RUN: llc %s -o - -enable-shrink-wrap=false -ifcvt-fn-start=1 -ifcvt-fn-stop=0 -mtriple=thumbv7-apple-ios \
[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; RUN: | FileCheck %s --check-prefix=THUMB-DISABLE
[ARM] Make the frame lowering code ready for shrink-wrapping. Shrink-wrapping can now be tested on ARM with -enable-shrink-wrap. Related to <rdar://problem/20821730> llvm-svn: 242908
2015-07-23 00:34:37 +08:00
;
; Note: Lots of tests use inline asm instead of regular calls.
; This allows to have a better control on what the allocation will do.
; Otherwise, we may have spill right in the entry block, defeating
; shrink-wrapping. Moreover, some of the inline asm statements (nop)
; are here to ensure that the related paths do not end up as critical
; edges.
; Also disable the late if-converter as it makes harder to reason on
; the diffs.
; Initial motivating example: Simple diamond with a call just on one side.
[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; foo:
[ARM] Make the frame lowering code ready for shrink-wrapping. Shrink-wrapping can now be tested on ARM with -enable-shrink-wrap. Related to <rdar://problem/20821730> llvm-svn: 242908
2015-07-23 00:34:37 +08:00
;
; Compare the arguments and jump to exit.
; No prologue needed.
[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; cmp r0, r1
; bge [[EXIT_LABEL:LBB[0-9_]+]]
[ARM] Make the frame lowering code ready for shrink-wrapping. Shrink-wrapping can now be tested on ARM with -enable-shrink-wrap. Related to <rdar://problem/20821730> llvm-svn: 242908
2015-07-23 00:34:37 +08:00
;
; Prologue code.
[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; push {r7, lr}
; mov r7, sp
[ARM] Make the frame lowering code ready for shrink-wrapping. Shrink-wrapping can now be tested on ARM with -enable-shrink-wrap. Related to <rdar://problem/20821730> llvm-svn: 242908
2015-07-23 00:34:37 +08:00
;;
; Compare the arguments and jump to exit.
; After the prologue is set.
[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; sub sp
; cmp r0, r1
; bge [[EXIT_LABEL:LBB[0-9_]+]]
[ARM] Make the frame lowering code ready for shrink-wrapping. Shrink-wrapping can now be tested on ARM with -enable-shrink-wrap. Related to <rdar://problem/20821730> llvm-svn: 242908
2015-07-23 00:34:37 +08:00
;
; Store %a in the alloca.
[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; push {r0}
; str r0, [sp, #-4]
; str r0, [sp]
[ARM] Make the frame lowering code ready for shrink-wrapping. Shrink-wrapping can now be tested on ARM with -enable-shrink-wrap. Related to <rdar://problem/20821730> llvm-svn: 242908
2015-07-23 00:34:37 +08:00
; Set the alloca address in the second argument.
[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; mov r1, sp
[ARM] Make the frame lowering code ready for shrink-wrapping. Shrink-wrapping can now be tested on ARM with -enable-shrink-wrap. Related to <rdar://problem/20821730> llvm-svn: 242908
2015-07-23 00:34:37 +08:00
; Set the first argument to zero.
[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; mov{{s?}} r0, #0
; bl{{x?}} _doSomething
[ARM] Make the frame lowering code ready for shrink-wrapping. Shrink-wrapping can now be tested on ARM with -enable-shrink-wrap. Related to <rdar://problem/20821730> llvm-svn: 242908
2015-07-23 00:34:37 +08:00
;
; With shrink-wrapping, epilogue is just after the call.
[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; mov sp, r7
; add sp, #4
; pop{{(\.w)?}} {r7, lr}
[ARM] Make the frame lowering code ready for shrink-wrapping. Shrink-wrapping can now be tested on ARM with -enable-shrink-wrap. Related to <rdar://problem/20821730> llvm-svn: 242908
2015-07-23 00:34:37 +08:00
;
[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; [[EXIT_LABEL]]:
[ARM] Make the frame lowering code ready for shrink-wrapping. Shrink-wrapping can now be tested on ARM with -enable-shrink-wrap. Related to <rdar://problem/20821730> llvm-svn: 242908
2015-07-23 00:34:37 +08:00
;
; Without shrink-wrapping, epilogue is in the exit block.
; Epilogue code. (What we pop does not matter.)
[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; mov sp, r7
; add sp,
; pop {r7, pc}
[ARM] Make the frame lowering code ready for shrink-wrapping. Shrink-wrapping can now be tested on ARM with -enable-shrink-wrap. Related to <rdar://problem/20821730> llvm-svn: 242908
2015-07-23 00:34:37 +08:00
;
[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; bx lr
[ARM] Generate consistent frame records for Thumb2 There is not an official documented ABI for frame pointers in Thumb2, but we should try to emit something which is useful. We use r7 as the frame pointer for Thumb code, which currently means that if a function needs to save a high register (r8-r11), it will get pushed to the stack between the frame pointer (r7) and link register (r14). This means that while a stack unwinder can follow the chain of frame pointers up the stack, it cannot know the offset to lr, so does not know which functions correspond to the stack frames. To fix this, we need to push the callee-saved registers in two batches, with the first push saving the low registers, fp and lr, and the second push saving the high registers. This is already implemented, but previously only used for iOS. This patch turns it on for all Thumb2 targets when frame pointers are required by the ABI, and the frame pointer is r7 (Windows uses r11, so this isn't a problem there). If frame pointer elimination is enabled we still emit a single push/pop even if we need a frame pointer for other reasons, to avoid increasing code size. We must also ensure that lr is pushed to the stack when using a frame pointer, so that we end up with a complete frame record. Situations that could cause this were rare, because we already push lr in most situations so that we can return using the pop instruction. Differential Revision: https://reviews.llvm.org/D23516 llvm-svn: 279506
2016-08-23 17:19:22 +08:00
define i32 @foo(i32 %a, i32 %b) "no-frame-pointer-elim"="true" {
[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; ARM-ENABLE-LABEL: foo:
; ARM-ENABLE: @ %bb.0:
; ARM-ENABLE-NEXT: cmp r0, r1
; ARM-ENABLE-NEXT: bge LBB0_2
; ARM-ENABLE-NEXT: @ %bb.1: @ %true
; ARM-ENABLE-NEXT: push {r7, lr}
; ARM-ENABLE-NEXT: mov r7, sp
; ARM-ENABLE-NEXT: push {r0}
; ARM-ENABLE-NEXT: mov r1, sp
; ARM-ENABLE-NEXT: mov r0, #0
; ARM-ENABLE-NEXT: bl _doSomething
; ARM-ENABLE-NEXT: mov sp, r7
; ARM-ENABLE-NEXT: pop {r7, lr}
; ARM-ENABLE-NEXT: LBB0_2: @ %false
; ARM-ENABLE-NEXT: bx lr
;
; ARM-DISABLE-LABEL: foo:
; ARM-DISABLE: @ %bb.0:
; ARM-DISABLE-NEXT: push {r7, lr}
; ARM-DISABLE-NEXT: mov r7, sp
; ARM-DISABLE-NEXT: sub sp, sp, #4
; ARM-DISABLE-NEXT: cmp r0, r1
; ARM-DISABLE-NEXT: bge LBB0_2
; ARM-DISABLE-NEXT: @ %bb.1: @ %true
; ARM-DISABLE-NEXT: str r0, [sp]
; ARM-DISABLE-NEXT: mov r1, sp
; ARM-DISABLE-NEXT: mov r0, #0
; ARM-DISABLE-NEXT: bl _doSomething
; ARM-DISABLE-NEXT: LBB0_2: @ %false
; ARM-DISABLE-NEXT: mov sp, r7
; ARM-DISABLE-NEXT: pop {r7, pc}
;
; THUMB-ENABLE-LABEL: foo:
; THUMB-ENABLE: @ %bb.0:
; THUMB-ENABLE-NEXT: cmp r0, r1
; THUMB-ENABLE-NEXT: bge LBB0_2
; THUMB-ENABLE-NEXT: @ %bb.1: @ %true
; THUMB-ENABLE-NEXT: push {r7, lr}
; THUMB-ENABLE-NEXT: mov r7, sp
; THUMB-ENABLE-NEXT: str r0, [sp, #-4]!
; THUMB-ENABLE-NEXT: mov r1, sp
; THUMB-ENABLE-NEXT: movs r0, #0
; THUMB-ENABLE-NEXT: bl _doSomething
; THUMB-ENABLE-NEXT: add sp, #4
; THUMB-ENABLE-NEXT: pop.w {r7, lr}
; THUMB-ENABLE-NEXT: LBB0_2: @ %false
; THUMB-ENABLE-NEXT: bx lr
;
; THUMB-DISABLE-LABEL: foo:
; THUMB-DISABLE: @ %bb.0:
; THUMB-DISABLE-NEXT: push {r7, lr}
; THUMB-DISABLE-NEXT: mov r7, sp
; THUMB-DISABLE-NEXT: sub sp, #4
; THUMB-DISABLE-NEXT: cmp r0, r1
; THUMB-DISABLE-NEXT: bge LBB0_2
; THUMB-DISABLE-NEXT: @ %bb.1: @ %true
; THUMB-DISABLE-NEXT: str r0, [sp]
; THUMB-DISABLE-NEXT: mov r1, sp
; THUMB-DISABLE-NEXT: movs r0, #0
; THUMB-DISABLE-NEXT: bl _doSomething
; THUMB-DISABLE-NEXT: LBB0_2: @ %false
; THUMB-DISABLE-NEXT: add sp, #4
; THUMB-DISABLE-NEXT: pop {r7, pc}
[ARM] Make the frame lowering code ready for shrink-wrapping. Shrink-wrapping can now be tested on ARM with -enable-shrink-wrap. Related to <rdar://problem/20821730> llvm-svn: 242908
2015-07-23 00:34:37 +08:00
%tmp = alloca i32, align 4
%tmp2 = icmp slt i32 %a, %b
br i1 %tmp2, label %true, label %false
true:
store i32 %a, i32* %tmp, align 4
%tmp4 = call i32 @doSomething(i32 0, i32* %tmp)
br label %false
false:
%tmp.0 = phi i32 [ %tmp4, %true ], [ %a, %0 ]
ret i32 %tmp.0
}
; Function Attrs: optsize
declare i32 @doSomething(i32, i32*)
; Check that we do not perform the restore inside the loop whereas the save
; is outside.
[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; freqSaveAndRestoreOutsideLoop:
[ARM] Make the frame lowering code ready for shrink-wrapping. Shrink-wrapping can now be tested on ARM with -enable-shrink-wrap. Related to <rdar://problem/20821730> llvm-svn: 242908
2015-07-23 00:34:37 +08:00
;
; Shrink-wrapping allows to skip the prologue in the else case.
[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; cmp r0, #0
; beq [[ELSE_LABEL:LBB[0-9_]+]]
; cbz r0, [[ELSE_LABEL:LBB[0-9_]+]]
[ARM] Make the frame lowering code ready for shrink-wrapping. Shrink-wrapping can now be tested on ARM with -enable-shrink-wrap. Related to <rdar://problem/20821730> llvm-svn: 242908
2015-07-23 00:34:37 +08:00
;
; Prologue code.
; Make sure we save the CSR used in the inline asm: r4.
[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; push {r4, r7, lr}
; add r7, sp, #4
[ARM] Make the frame lowering code ready for shrink-wrapping. Shrink-wrapping can now be tested on ARM with -enable-shrink-wrap. Related to <rdar://problem/20821730> llvm-svn: 242908
2015-07-23 00:34:37 +08:00
;
[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; cmp r0, #0
; beq [[ELSE_LABEL:LBB[0-9_]+]]
; cbz r0, [[ELSE_LABEL:LBB[0-9_]+]]
[ARM] Make the frame lowering code ready for shrink-wrapping. Shrink-wrapping can now be tested on ARM with -enable-shrink-wrap. Related to <rdar://problem/20821730> llvm-svn: 242908
2015-07-23 00:34:37 +08:00
;
; SUM is in r0 because it is coalesced with the second
; argument on the else path.
[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; mov{{s?}} [[SUM:r0]], #0
; mov{{s?}} [[IV:r[0-9]+]], #10
[ARM] Make the frame lowering code ready for shrink-wrapping. Shrink-wrapping can now be tested on ARM with -enable-shrink-wrap. Related to <rdar://problem/20821730> llvm-svn: 242908
2015-07-23 00:34:37 +08:00
;
; Next BB.
[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; [[LOOP:LBB[0-9_]+]]: @ %for.body
; mov{{(\.w)?}} [[TMP:r[0-9]+]], #1
; add [[SUM]], [[TMP]], [[SUM]]
; add [[SUM]], [[TMP]]
; subs [[IV]], [[IV]], #1
; subs [[IV]], #1
; bne [[LOOP]]
[ARM] Make the frame lowering code ready for shrink-wrapping. Shrink-wrapping can now be tested on ARM with -enable-shrink-wrap. Related to <rdar://problem/20821730> llvm-svn: 242908
2015-07-23 00:34:37 +08:00
;
; Next BB.
; SUM << 3.
[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; lsl{{s?}} [[SUM]], [[SUM]], #3
; pop {r4, r7, pc}
[ARM] Make the frame lowering code ready for shrink-wrapping. Shrink-wrapping can now be tested on ARM with -enable-shrink-wrap. Related to <rdar://problem/20821730> llvm-svn: 242908
2015-07-23 00:34:37 +08:00
;
; Duplicated epilogue.
[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; pop {r4, r7, pc}
[ARM] Make the frame lowering code ready for shrink-wrapping. Shrink-wrapping can now be tested on ARM with -enable-shrink-wrap. Related to <rdar://problem/20821730> llvm-svn: 242908
2015-07-23 00:34:37 +08:00
;
[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; [[ELSE_LABEL]]: @ %if.else
[ARM] Make the frame lowering code ready for shrink-wrapping. Shrink-wrapping can now be tested on ARM with -enable-shrink-wrap. Related to <rdar://problem/20821730> llvm-svn: 242908
2015-07-23 00:34:37 +08:00
; Shift second argument by one and store into returned register.
[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; lsl{{s?}} r0, r1, #1
; pop {r4, r7, pc}
[ARM] Make the frame lowering code ready for shrink-wrapping. Shrink-wrapping can now be tested on ARM with -enable-shrink-wrap. Related to <rdar://problem/20821730> llvm-svn: 242908
2015-07-23 00:34:37 +08:00
;
[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; bx lr
[ARM] Generate consistent frame records for Thumb2 There is not an official documented ABI for frame pointers in Thumb2, but we should try to emit something which is useful. We use r7 as the frame pointer for Thumb code, which currently means that if a function needs to save a high register (r8-r11), it will get pushed to the stack between the frame pointer (r7) and link register (r14). This means that while a stack unwinder can follow the chain of frame pointers up the stack, it cannot know the offset to lr, so does not know which functions correspond to the stack frames. To fix this, we need to push the callee-saved registers in two batches, with the first push saving the low registers, fp and lr, and the second push saving the high registers. This is already implemented, but previously only used for iOS. This patch turns it on for all Thumb2 targets when frame pointers are required by the ABI, and the frame pointer is r7 (Windows uses r11, so this isn't a problem there). If frame pointer elimination is enabled we still emit a single push/pop even if we need a frame pointer for other reasons, to avoid increasing code size. We must also ensure that lr is pushed to the stack when using a frame pointer, so that we end up with a complete frame record. Situations that could cause this were rare, because we already push lr in most situations so that we can return using the pop instruction. Differential Revision: https://reviews.llvm.org/D23516 llvm-svn: 279506
2016-08-23 17:19:22 +08:00
define i32 @freqSaveAndRestoreOutsideLoop(i32 %cond, i32 %N) "no-frame-pointer-elim"="true" {
[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; ARM-ENABLE-LABEL: freqSaveAndRestoreOutsideLoop:
; ARM-ENABLE: @ %bb.0: @ %entry
; ARM-ENABLE-NEXT: cmp r0, #0
; ARM-ENABLE-NEXT: beq LBB1_4
; ARM-ENABLE-NEXT: @ %bb.1: @ %for.preheader
; ARM-ENABLE-NEXT: push {r4, r7, lr}
; ARM-ENABLE-NEXT: add r7, sp, #4
; ARM-ENABLE-NEXT: mov r0, #0
; ARM-ENABLE-NEXT: mov r1, #10
; ARM-ENABLE-NEXT: @ InlineAsm Start
; ARM-ENABLE-NEXT: nop
; ARM-ENABLE-NEXT: @ InlineAsm End
; ARM-ENABLE-NEXT: LBB1_2: @ %for.body
; ARM-ENABLE-NEXT: @ =>This Inner Loop Header: Depth=1
; ARM-ENABLE-NEXT: @ InlineAsm Start
; ARM-ENABLE-NEXT: mov r2, #1
; ARM-ENABLE-NEXT: @ InlineAsm End
; ARM-ENABLE-NEXT: add r0, r2, r0
; ARM-ENABLE-NEXT: subs r1, r1, #1
; ARM-ENABLE-NEXT: bne LBB1_2
; ARM-ENABLE-NEXT: @ %bb.3: @ %for.end
; ARM-ENABLE-NEXT: lsl r0, r0, #3
; ARM-ENABLE-NEXT: pop {r4, r7, pc}
; ARM-ENABLE-NEXT: LBB1_4: @ %if.else
; ARM-ENABLE-NEXT: lsl r0, r1, #1
; ARM-ENABLE-NEXT: bx lr
;
; ARM-DISABLE-LABEL: freqSaveAndRestoreOutsideLoop:
; ARM-DISABLE: @ %bb.0: @ %entry
; ARM-DISABLE-NEXT: push {r4, r7, lr}
; ARM-DISABLE-NEXT: add r7, sp, #4
; ARM-DISABLE-NEXT: cmp r0, #0
; ARM-DISABLE-NEXT: beq LBB1_4
; ARM-DISABLE-NEXT: @ %bb.1: @ %for.preheader
; ARM-DISABLE-NEXT: mov r0, #0
; ARM-DISABLE-NEXT: mov r1, #10
; ARM-DISABLE-NEXT: @ InlineAsm Start
; ARM-DISABLE-NEXT: nop
; ARM-DISABLE-NEXT: @ InlineAsm End
; ARM-DISABLE-NEXT: LBB1_2: @ %for.body
; ARM-DISABLE-NEXT: @ =>This Inner Loop Header: Depth=1
; ARM-DISABLE-NEXT: @ InlineAsm Start
; ARM-DISABLE-NEXT: mov r2, #1
; ARM-DISABLE-NEXT: @ InlineAsm End
; ARM-DISABLE-NEXT: add r0, r2, r0
; ARM-DISABLE-NEXT: subs r1, r1, #1
; ARM-DISABLE-NEXT: bne LBB1_2
; ARM-DISABLE-NEXT: @ %bb.3: @ %for.end
; ARM-DISABLE-NEXT: lsl r0, r0, #3
; ARM-DISABLE-NEXT: pop {r4, r7, pc}
; ARM-DISABLE-NEXT: LBB1_4: @ %if.else
; ARM-DISABLE-NEXT: lsl r0, r1, #1
; ARM-DISABLE-NEXT: pop {r4, r7, pc}
;
; THUMB-ENABLE-LABEL: freqSaveAndRestoreOutsideLoop:
; THUMB-ENABLE: @ %bb.0: @ %entry
; THUMB-ENABLE-NEXT: cbz r0, LBB1_4
; THUMB-ENABLE-NEXT: @ %bb.1: @ %for.preheader
; THUMB-ENABLE-NEXT: push {r4, r7, lr}
; THUMB-ENABLE-NEXT: add r7, sp, #4
; THUMB-ENABLE-NEXT: movs r0, #0
; THUMB-ENABLE-NEXT: movs r1, #10
; THUMB-ENABLE-NEXT: @ InlineAsm Start
; THUMB-ENABLE-NEXT: nop
; THUMB-ENABLE-NEXT: @ InlineAsm End
; THUMB-ENABLE-NEXT: LBB1_2: @ %for.body
; THUMB-ENABLE-NEXT: @ =>This Inner Loop Header: Depth=1
; THUMB-ENABLE-NEXT: @ InlineAsm Start
; THUMB-ENABLE-NEXT: mov.w r2, #1
; THUMB-ENABLE-NEXT: @ InlineAsm End
; THUMB-ENABLE-NEXT: add r0, r2
; THUMB-ENABLE-NEXT: subs r1, #1
; THUMB-ENABLE-NEXT: bne LBB1_2
; THUMB-ENABLE-NEXT: @ %bb.3: @ %for.end
; THUMB-ENABLE-NEXT: lsls r0, r0, #3
; THUMB-ENABLE-NEXT: pop {r4, r7, pc}
; THUMB-ENABLE-NEXT: LBB1_4: @ %if.else
; THUMB-ENABLE-NEXT: lsls r0, r1, #1
; THUMB-ENABLE-NEXT: bx lr
;
; THUMB-DISABLE-LABEL: freqSaveAndRestoreOutsideLoop:
; THUMB-DISABLE: @ %bb.0: @ %entry
; THUMB-DISABLE-NEXT: push {r4, r7, lr}
; THUMB-DISABLE-NEXT: add r7, sp, #4
; THUMB-DISABLE-NEXT: cbz r0, LBB1_4
; THUMB-DISABLE-NEXT: @ %bb.1: @ %for.preheader
; THUMB-DISABLE-NEXT: movs r0, #0
; THUMB-DISABLE-NEXT: movs r1, #10
; THUMB-DISABLE-NEXT: @ InlineAsm Start
; THUMB-DISABLE-NEXT: nop
; THUMB-DISABLE-NEXT: @ InlineAsm End
; THUMB-DISABLE-NEXT: LBB1_2: @ %for.body
; THUMB-DISABLE-NEXT: @ =>This Inner Loop Header: Depth=1
; THUMB-DISABLE-NEXT: @ InlineAsm Start
; THUMB-DISABLE-NEXT: mov.w r2, #1
; THUMB-DISABLE-NEXT: @ InlineAsm End
; THUMB-DISABLE-NEXT: add r0, r2
; THUMB-DISABLE-NEXT: subs r1, #1
; THUMB-DISABLE-NEXT: bne LBB1_2
; THUMB-DISABLE-NEXT: @ %bb.3: @ %for.end
; THUMB-DISABLE-NEXT: lsls r0, r0, #3
; THUMB-DISABLE-NEXT: pop {r4, r7, pc}
; THUMB-DISABLE-NEXT: LBB1_4: @ %if.else
; THUMB-DISABLE-NEXT: lsls r0, r1, #1
; THUMB-DISABLE-NEXT: pop {r4, r7, pc}
[ARM] Make the frame lowering code ready for shrink-wrapping. Shrink-wrapping can now be tested on ARM with -enable-shrink-wrap. Related to <rdar://problem/20821730> llvm-svn: 242908
2015-07-23 00:34:37 +08:00
entry:
%tobool = icmp eq i32 %cond, 0
br i1 %tobool, label %if.else, label %for.preheader
for.preheader:
tail call void asm "nop", ""()
br label %for.body
for.body: ; preds = %entry, %for.body
%i.05 = phi i32 [ %inc, %for.body ], [ 0, %for.preheader ]
%sum.04 = phi i32 [ %add, %for.body ], [ 0, %for.preheader ]
%call = tail call i32 asm sideeffect "mov $0, #1", "=r,~{r4}"()
%add = add nsw i32 %call, %sum.04
%inc = add nuw nsw i32 %i.05, 1
%exitcond = icmp eq i32 %inc, 10
br i1 %exitcond, label %for.end, label %for.body
for.end: ; preds = %for.body
%shl = shl i32 %add, 3
br label %if.end
if.else: ; preds = %entry
%mul = shl nsw i32 %N, 1
br label %if.end
if.end: ; preds = %if.else, %for.end
%sum.1 = phi i32 [ %shl, %for.end ], [ %mul, %if.else ]
ret i32 %sum.1
}
declare i32 @something(...)
; Check that we do not perform the shrink-wrapping inside the loop even
; though that would be legal. The cost model must prevent that.
[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; freqSaveAndRestoreOutsideLoop2:
[ARM] Make the frame lowering code ready for shrink-wrapping. Shrink-wrapping can now be tested on ARM with -enable-shrink-wrap. Related to <rdar://problem/20821730> llvm-svn: 242908
2015-07-23 00:34:37 +08:00
; Prologue code.
; Make sure we save the CSR used in the inline asm: r4.
[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; push {r4
; mov{{s?}} [[SUM:r0]], #0
; mov{{s?}} [[IV:r[0-9]+]], #10
; nop
[ARM] Make the frame lowering code ready for shrink-wrapping. Shrink-wrapping can now be tested on ARM with -enable-shrink-wrap. Related to <rdar://problem/20821730> llvm-svn: 242908
2015-07-23 00:34:37 +08:00
; Next BB.
[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; [[LOOP_LABEL:LBB[0-9_]+]]: @ %for.body
; mov{{(\.w)?}} [[TMP:r[0-9]+]], #1
; add [[SUM]], [[TMP]], [[SUM]]
; add [[SUM]], [[TMP]]
; subs [[IV]], [[IV]], #1
; subs [[IV]], #1
; bne [[LOOP_LABEL]]
[ARM] Make the frame lowering code ready for shrink-wrapping. Shrink-wrapping can now be tested on ARM with -enable-shrink-wrap. Related to <rdar://problem/20821730> llvm-svn: 242908
2015-07-23 00:34:37 +08:00
; Next BB.
[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; @ %for.exit
; nop
; pop {r4
[ARM] Generate consistent frame records for Thumb2 There is not an official documented ABI for frame pointers in Thumb2, but we should try to emit something which is useful. We use r7 as the frame pointer for Thumb code, which currently means that if a function needs to save a high register (r8-r11), it will get pushed to the stack between the frame pointer (r7) and link register (r14). This means that while a stack unwinder can follow the chain of frame pointers up the stack, it cannot know the offset to lr, so does not know which functions correspond to the stack frames. To fix this, we need to push the callee-saved registers in two batches, with the first push saving the low registers, fp and lr, and the second push saving the high registers. This is already implemented, but previously only used for iOS. This patch turns it on for all Thumb2 targets when frame pointers are required by the ABI, and the frame pointer is r7 (Windows uses r11, so this isn't a problem there). If frame pointer elimination is enabled we still emit a single push/pop even if we need a frame pointer for other reasons, to avoid increasing code size. We must also ensure that lr is pushed to the stack when using a frame pointer, so that we end up with a complete frame record. Situations that could cause this were rare, because we already push lr in most situations so that we can return using the pop instruction. Differential Revision: https://reviews.llvm.org/D23516 llvm-svn: 279506
2016-08-23 17:19:22 +08:00
define i32 @freqSaveAndRestoreOutsideLoop2(i32 %cond) "no-frame-pointer-elim"="true" {
[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; ARM-LABEL: freqSaveAndRestoreOutsideLoop2:
; ARM: @ %bb.0: @ %entry
; ARM-NEXT: push {r4, r7, lr}
; ARM-NEXT: add r7, sp, #4
; ARM-NEXT: mov r0, #0
; ARM-NEXT: mov r1, #10
; ARM-NEXT: @ InlineAsm Start
; ARM-NEXT: nop
; ARM-NEXT: @ InlineAsm End
; ARM-NEXT: LBB2_1: @ %for.body
; ARM-NEXT: @ =>This Inner Loop Header: Depth=1
; ARM-NEXT: @ InlineAsm Start
; ARM-NEXT: mov r2, #1
; ARM-NEXT: @ InlineAsm End
; ARM-NEXT: add r0, r2, r0
; ARM-NEXT: subs r1, r1, #1
; ARM-NEXT: bne LBB2_1
; ARM-NEXT: @ %bb.2: @ %for.exit
; ARM-NEXT: @ InlineAsm Start
; ARM-NEXT: nop
; ARM-NEXT: @ InlineAsm End
; ARM-NEXT: pop {r4, r7, pc}
;
; THUMB-LABEL: freqSaveAndRestoreOutsideLoop2:
; THUMB: @ %bb.0: @ %entry
; THUMB-NEXT: push {r4, r7, lr}
; THUMB-NEXT: add r7, sp, #4
; THUMB-NEXT: movs r0, #0
; THUMB-NEXT: movs r1, #10
; THUMB-NEXT: @ InlineAsm Start
; THUMB-NEXT: nop
; THUMB-NEXT: @ InlineAsm End
; THUMB-NEXT: LBB2_1: @ %for.body
; THUMB-NEXT: @ =>This Inner Loop Header: Depth=1
; THUMB-NEXT: @ InlineAsm Start
; THUMB-NEXT: mov.w r2, #1
; THUMB-NEXT: @ InlineAsm End
; THUMB-NEXT: add r0, r2
; THUMB-NEXT: subs r1, #1
; THUMB-NEXT: bne LBB2_1
; THUMB-NEXT: @ %bb.2: @ %for.exit
; THUMB-NEXT: @ InlineAsm Start
; THUMB-NEXT: nop
; THUMB-NEXT: @ InlineAsm End
; THUMB-NEXT: pop {r4, r7, pc}
; ARM-ENABLE-LABEL: freqSaveAndRestoreOutsideLoop2:
; ARM-ENABLE: @ %bb.0: @ %entry
; ARM-ENABLE-NEXT: push {r4, r7, lr}
; ARM-ENABLE-NEXT: add r7, sp, #4
; ARM-ENABLE-NEXT: mov r0, #0
; ARM-ENABLE-NEXT: mov r1, #10
; ARM-ENABLE-NEXT: @ InlineAsm Start
; ARM-ENABLE-NEXT: nop
; ARM-ENABLE-NEXT: @ InlineAsm End
; ARM-ENABLE-NEXT: LBB2_1: @ %for.body
; ARM-ENABLE-NEXT: @ =>This Inner Loop Header: Depth=1
; ARM-ENABLE-NEXT: @ InlineAsm Start
; ARM-ENABLE-NEXT: mov r2, #1
; ARM-ENABLE-NEXT: @ InlineAsm End
; ARM-ENABLE-NEXT: add r0, r2, r0
; ARM-ENABLE-NEXT: subs r1, r1, #1
; ARM-ENABLE-NEXT: bne LBB2_1
; ARM-ENABLE-NEXT: @ %bb.2: @ %for.exit
; ARM-ENABLE-NEXT: @ InlineAsm Start
; ARM-ENABLE-NEXT: nop
; ARM-ENABLE-NEXT: @ InlineAsm End
; ARM-ENABLE-NEXT: pop {r4, r7, pc}
;
; ARM-DISABLE-LABEL: freqSaveAndRestoreOutsideLoop2:
; ARM-DISABLE: @ %bb.0: @ %entry
; ARM-DISABLE-NEXT: push {r4, r7, lr}
; ARM-DISABLE-NEXT: add r7, sp, #4
; ARM-DISABLE-NEXT: mov r0, #0
; ARM-DISABLE-NEXT: mov r1, #10
; ARM-DISABLE-NEXT: @ InlineAsm Start
; ARM-DISABLE-NEXT: nop
; ARM-DISABLE-NEXT: @ InlineAsm End
; ARM-DISABLE-NEXT: LBB2_1: @ %for.body
; ARM-DISABLE-NEXT: @ =>This Inner Loop Header: Depth=1
; ARM-DISABLE-NEXT: @ InlineAsm Start
; ARM-DISABLE-NEXT: mov r2, #1
; ARM-DISABLE-NEXT: @ InlineAsm End
; ARM-DISABLE-NEXT: add r0, r2, r0
; ARM-DISABLE-NEXT: subs r1, r1, #1
; ARM-DISABLE-NEXT: bne LBB2_1
; ARM-DISABLE-NEXT: @ %bb.2: @ %for.exit
; ARM-DISABLE-NEXT: @ InlineAsm Start
; ARM-DISABLE-NEXT: nop
; ARM-DISABLE-NEXT: @ InlineAsm End
; ARM-DISABLE-NEXT: pop {r4, r7, pc}
;
; THUMB-ENABLE-LABEL: freqSaveAndRestoreOutsideLoop2:
; THUMB-ENABLE: @ %bb.0: @ %entry
; THUMB-ENABLE-NEXT: push {r4, r7, lr}
; THUMB-ENABLE-NEXT: add r7, sp, #4
; THUMB-ENABLE-NEXT: movs r0, #0
; THUMB-ENABLE-NEXT: movs r1, #10
; THUMB-ENABLE-NEXT: @ InlineAsm Start
; THUMB-ENABLE-NEXT: nop
; THUMB-ENABLE-NEXT: @ InlineAsm End
; THUMB-ENABLE-NEXT: LBB2_1: @ %for.body
; THUMB-ENABLE-NEXT: @ =>This Inner Loop Header: Depth=1
; THUMB-ENABLE-NEXT: @ InlineAsm Start
; THUMB-ENABLE-NEXT: mov.w r2, #1
; THUMB-ENABLE-NEXT: @ InlineAsm End
; THUMB-ENABLE-NEXT: add r0, r2
; THUMB-ENABLE-NEXT: subs r1, #1
; THUMB-ENABLE-NEXT: bne LBB2_1
; THUMB-ENABLE-NEXT: @ %bb.2: @ %for.exit
; THUMB-ENABLE-NEXT: @ InlineAsm Start
; THUMB-ENABLE-NEXT: nop
; THUMB-ENABLE-NEXT: @ InlineAsm End
; THUMB-ENABLE-NEXT: pop {r4, r7, pc}
;
; THUMB-DISABLE-LABEL: freqSaveAndRestoreOutsideLoop2:
; THUMB-DISABLE: @ %bb.0: @ %entry
; THUMB-DISABLE-NEXT: push {r4, r7, lr}
; THUMB-DISABLE-NEXT: add r7, sp, #4
; THUMB-DISABLE-NEXT: movs r0, #0
; THUMB-DISABLE-NEXT: movs r1, #10
; THUMB-DISABLE-NEXT: @ InlineAsm Start
; THUMB-DISABLE-NEXT: nop
; THUMB-DISABLE-NEXT: @ InlineAsm End
; THUMB-DISABLE-NEXT: LBB2_1: @ %for.body
; THUMB-DISABLE-NEXT: @ =>This Inner Loop Header: Depth=1
; THUMB-DISABLE-NEXT: @ InlineAsm Start
; THUMB-DISABLE-NEXT: mov.w r2, #1
; THUMB-DISABLE-NEXT: @ InlineAsm End
; THUMB-DISABLE-NEXT: add r0, r2
; THUMB-DISABLE-NEXT: subs r1, #1
; THUMB-DISABLE-NEXT: bne LBB2_1
; THUMB-DISABLE-NEXT: @ %bb.2: @ %for.exit
; THUMB-DISABLE-NEXT: @ InlineAsm Start
; THUMB-DISABLE-NEXT: nop
; THUMB-DISABLE-NEXT: @ InlineAsm End
; THUMB-DISABLE-NEXT: pop {r4, r7, pc}
[ARM] Make the frame lowering code ready for shrink-wrapping. Shrink-wrapping can now be tested on ARM with -enable-shrink-wrap. Related to <rdar://problem/20821730> llvm-svn: 242908
2015-07-23 00:34:37 +08:00
entry:
br label %for.preheader
for.preheader:
tail call void asm "nop", ""()
br label %for.body
for.body: ; preds = %for.body, %entry
%i.04 = phi i32 [ 0, %for.preheader ], [ %inc, %for.body ]
%sum.03 = phi i32 [ 0, %for.preheader ], [ %add, %for.body ]
%call = tail call i32 asm sideeffect "mov $0, #1", "=r,~{r4}"()
%add = add nsw i32 %call, %sum.03
%inc = add nuw nsw i32 %i.04, 1
%exitcond = icmp eq i32 %inc, 10
br i1 %exitcond, label %for.exit, label %for.body
for.exit:
tail call void asm "nop", ""()
br label %for.end
for.end: ; preds = %for.body
ret i32 %add
}
; Check with a more complex case that we do not have save within the loop and
; restore outside.
[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; loopInfoSaveOutsideLoop:
[ARM] Make the frame lowering code ready for shrink-wrapping. Shrink-wrapping can now be tested on ARM with -enable-shrink-wrap. Related to <rdar://problem/20821730> llvm-svn: 242908
2015-07-23 00:34:37 +08:00
;
[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; cmp r0, #0
; beq [[ELSE_LABEL:LBB[0-9_]+]]
; cbz r0, [[ELSE_LABEL:LBB[0-9_]+]]
[ARM] Make the frame lowering code ready for shrink-wrapping. Shrink-wrapping can now be tested on ARM with -enable-shrink-wrap. Related to <rdar://problem/20821730> llvm-svn: 242908
2015-07-23 00:34:37 +08:00
;
; Prologue code.
; Make sure we save the CSR used in the inline asm: r4.
[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; push {r4, r7, lr}
; add r7, sp, #4
[ARM] Make the frame lowering code ready for shrink-wrapping. Shrink-wrapping can now be tested on ARM with -enable-shrink-wrap. Related to <rdar://problem/20821730> llvm-svn: 242908
2015-07-23 00:34:37 +08:00
;
[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; cmp r0, #0
; beq [[ELSE_LABEL:LBB[0-9_]+]]
; cbz r0, [[ELSE_LABEL:LBB[0-9_]+]]
[ARM] Make the frame lowering code ready for shrink-wrapping. Shrink-wrapping can now be tested on ARM with -enable-shrink-wrap. Related to <rdar://problem/20821730> llvm-svn: 242908
2015-07-23 00:34:37 +08:00
;
; SUM is in r0 because it is coalesced with the second
; argument on the else path.
[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; mov{{s?}} [[SUM:r0]], #0
; mov{{s?}} [[IV:r[0-9]+]], #10
[ARM] Make the frame lowering code ready for shrink-wrapping. Shrink-wrapping can now be tested on ARM with -enable-shrink-wrap. Related to <rdar://problem/20821730> llvm-svn: 242908
2015-07-23 00:34:37 +08:00
;
; Next BB.
[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; [[LOOP:LBB[0-9_]+]]: @ %for.body
; mov{{(\.w)?}} [[TMP:r[0-9]+]], #1
; add [[SUM]], [[TMP]], [[SUM]]
; add [[SUM]], [[TMP]]
; subs [[IV]], [[IV]], #1
; subs [[IV]], #1
; bne [[LOOP]]
[ARM] Make the frame lowering code ready for shrink-wrapping. Shrink-wrapping can now be tested on ARM with -enable-shrink-wrap. Related to <rdar://problem/20821730> llvm-svn: 242908
2015-07-23 00:34:37 +08:00
;
; Next BB.
; SUM << 3.
[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; lsl{{s?}} [[SUM]], [[SUM]], #3
; pop {r4, r7, pc}
[ARM] Make the frame lowering code ready for shrink-wrapping. Shrink-wrapping can now be tested on ARM with -enable-shrink-wrap. Related to <rdar://problem/20821730> llvm-svn: 242908
2015-07-23 00:34:37 +08:00
;
; Duplicated epilogue.
[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; pop {r4, r7, pc}
[ARM] Make the frame lowering code ready for shrink-wrapping. Shrink-wrapping can now be tested on ARM with -enable-shrink-wrap. Related to <rdar://problem/20821730> llvm-svn: 242908
2015-07-23 00:34:37 +08:00
;
[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; [[ELSE_LABEL]]: @ %if.else
[ARM] Make the frame lowering code ready for shrink-wrapping. Shrink-wrapping can now be tested on ARM with -enable-shrink-wrap. Related to <rdar://problem/20821730> llvm-svn: 242908
2015-07-23 00:34:37 +08:00
; Shift second argument by one and store into returned register.
[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; lsl{{s?}} r0, r1, #1
; pop {r4, r7, pc}
[ARM] Make the frame lowering code ready for shrink-wrapping. Shrink-wrapping can now be tested on ARM with -enable-shrink-wrap. Related to <rdar://problem/20821730> llvm-svn: 242908
2015-07-23 00:34:37 +08:00
;
[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; bx lr
[ARM] Generate consistent frame records for Thumb2 There is not an official documented ABI for frame pointers in Thumb2, but we should try to emit something which is useful. We use r7 as the frame pointer for Thumb code, which currently means that if a function needs to save a high register (r8-r11), it will get pushed to the stack between the frame pointer (r7) and link register (r14). This means that while a stack unwinder can follow the chain of frame pointers up the stack, it cannot know the offset to lr, so does not know which functions correspond to the stack frames. To fix this, we need to push the callee-saved registers in two batches, with the first push saving the low registers, fp and lr, and the second push saving the high registers. This is already implemented, but previously only used for iOS. This patch turns it on for all Thumb2 targets when frame pointers are required by the ABI, and the frame pointer is r7 (Windows uses r11, so this isn't a problem there). If frame pointer elimination is enabled we still emit a single push/pop even if we need a frame pointer for other reasons, to avoid increasing code size. We must also ensure that lr is pushed to the stack when using a frame pointer, so that we end up with a complete frame record. Situations that could cause this were rare, because we already push lr in most situations so that we can return using the pop instruction. Differential Revision: https://reviews.llvm.org/D23516 llvm-svn: 279506
2016-08-23 17:19:22 +08:00
define i32 @loopInfoSaveOutsideLoop(i32 %cond, i32 %N) "no-frame-pointer-elim"="true" {
[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; ARM-ENABLE-LABEL: loopInfoSaveOutsideLoop:
; ARM-ENABLE: @ %bb.0: @ %entry
; ARM-ENABLE-NEXT: cmp r0, #0
; ARM-ENABLE-NEXT: beq LBB3_4
; ARM-ENABLE-NEXT: @ %bb.1: @ %for.preheader
; ARM-ENABLE-NEXT: push {r4, r7, lr}
; ARM-ENABLE-NEXT: add r7, sp, #4
; ARM-ENABLE-NEXT: mov r0, #0
; ARM-ENABLE-NEXT: mov r1, #10
; ARM-ENABLE-NEXT: @ InlineAsm Start
; ARM-ENABLE-NEXT: nop
; ARM-ENABLE-NEXT: @ InlineAsm End
; ARM-ENABLE-NEXT: LBB3_2: @ %for.body
; ARM-ENABLE-NEXT: @ =>This Inner Loop Header: Depth=1
; ARM-ENABLE-NEXT: @ InlineAsm Start
; ARM-ENABLE-NEXT: mov r2, #1
; ARM-ENABLE-NEXT: @ InlineAsm End
; ARM-ENABLE-NEXT: add r0, r2, r0
; ARM-ENABLE-NEXT: subs r1, r1, #1
; ARM-ENABLE-NEXT: bne LBB3_2
; ARM-ENABLE-NEXT: @ %bb.3: @ %for.end
; ARM-ENABLE-NEXT: lsl r0, r0, #3
; ARM-ENABLE-NEXT: @ InlineAsm Start
; ARM-ENABLE-NEXT: nop
; ARM-ENABLE-NEXT: @ InlineAsm End
; ARM-ENABLE-NEXT: pop {r4, r7, pc}
; ARM-ENABLE-NEXT: LBB3_4: @ %if.else
; ARM-ENABLE-NEXT: lsl r0, r1, #1
; ARM-ENABLE-NEXT: bx lr
;
; ARM-DISABLE-LABEL: loopInfoSaveOutsideLoop:
; ARM-DISABLE: @ %bb.0: @ %entry
; ARM-DISABLE-NEXT: push {r4, r7, lr}
; ARM-DISABLE-NEXT: add r7, sp, #4
; ARM-DISABLE-NEXT: cmp r0, #0
; ARM-DISABLE-NEXT: beq LBB3_4
; ARM-DISABLE-NEXT: @ %bb.1: @ %for.preheader
; ARM-DISABLE-NEXT: mov r0, #0
; ARM-DISABLE-NEXT: mov r1, #10
; ARM-DISABLE-NEXT: @ InlineAsm Start
; ARM-DISABLE-NEXT: nop
; ARM-DISABLE-NEXT: @ InlineAsm End
; ARM-DISABLE-NEXT: LBB3_2: @ %for.body
; ARM-DISABLE-NEXT: @ =>This Inner Loop Header: Depth=1
; ARM-DISABLE-NEXT: @ InlineAsm Start
; ARM-DISABLE-NEXT: mov r2, #1
; ARM-DISABLE-NEXT: @ InlineAsm End
; ARM-DISABLE-NEXT: add r0, r2, r0
; ARM-DISABLE-NEXT: subs r1, r1, #1
; ARM-DISABLE-NEXT: bne LBB3_2
; ARM-DISABLE-NEXT: @ %bb.3: @ %for.end
; ARM-DISABLE-NEXT: lsl r0, r0, #3
; ARM-DISABLE-NEXT: @ InlineAsm Start
; ARM-DISABLE-NEXT: nop
; ARM-DISABLE-NEXT: @ InlineAsm End
; ARM-DISABLE-NEXT: pop {r4, r7, pc}
; ARM-DISABLE-NEXT: LBB3_4: @ %if.else
; ARM-DISABLE-NEXT: lsl r0, r1, #1
; ARM-DISABLE-NEXT: pop {r4, r7, pc}
;
; THUMB-ENABLE-LABEL: loopInfoSaveOutsideLoop:
; THUMB-ENABLE: @ %bb.0: @ %entry
; THUMB-ENABLE-NEXT: cbz r0, LBB3_4
; THUMB-ENABLE-NEXT: @ %bb.1: @ %for.preheader
; THUMB-ENABLE-NEXT: push {r4, r7, lr}
; THUMB-ENABLE-NEXT: add r7, sp, #4
; THUMB-ENABLE-NEXT: movs r0, #0
; THUMB-ENABLE-NEXT: movs r1, #10
; THUMB-ENABLE-NEXT: @ InlineAsm Start
; THUMB-ENABLE-NEXT: nop
; THUMB-ENABLE-NEXT: @ InlineAsm End
; THUMB-ENABLE-NEXT: LBB3_2: @ %for.body
; THUMB-ENABLE-NEXT: @ =>This Inner Loop Header: Depth=1
; THUMB-ENABLE-NEXT: @ InlineAsm Start
; THUMB-ENABLE-NEXT: mov.w r2, #1
; THUMB-ENABLE-NEXT: @ InlineAsm End
; THUMB-ENABLE-NEXT: add r0, r2
; THUMB-ENABLE-NEXT: subs r1, #1
; THUMB-ENABLE-NEXT: bne LBB3_2
; THUMB-ENABLE-NEXT: @ %bb.3: @ %for.end
; THUMB-ENABLE-NEXT: lsls r0, r0, #3
; THUMB-ENABLE-NEXT: @ InlineAsm Start
; THUMB-ENABLE-NEXT: nop
; THUMB-ENABLE-NEXT: @ InlineAsm End
; THUMB-ENABLE-NEXT: pop {r4, r7, pc}
; THUMB-ENABLE-NEXT: LBB3_4: @ %if.else
; THUMB-ENABLE-NEXT: lsls r0, r1, #1
; THUMB-ENABLE-NEXT: bx lr
;
; THUMB-DISABLE-LABEL: loopInfoSaveOutsideLoop:
; THUMB-DISABLE: @ %bb.0: @ %entry
; THUMB-DISABLE-NEXT: push {r4, r7, lr}
; THUMB-DISABLE-NEXT: add r7, sp, #4
; THUMB-DISABLE-NEXT: cbz r0, LBB3_4
; THUMB-DISABLE-NEXT: @ %bb.1: @ %for.preheader
; THUMB-DISABLE-NEXT: movs r0, #0
; THUMB-DISABLE-NEXT: movs r1, #10
; THUMB-DISABLE-NEXT: @ InlineAsm Start
; THUMB-DISABLE-NEXT: nop
; THUMB-DISABLE-NEXT: @ InlineAsm End
; THUMB-DISABLE-NEXT: LBB3_2: @ %for.body
; THUMB-DISABLE-NEXT: @ =>This Inner Loop Header: Depth=1
; THUMB-DISABLE-NEXT: @ InlineAsm Start
; THUMB-DISABLE-NEXT: mov.w r2, #1
; THUMB-DISABLE-NEXT: @ InlineAsm End
; THUMB-DISABLE-NEXT: add r0, r2
; THUMB-DISABLE-NEXT: subs r1, #1
; THUMB-DISABLE-NEXT: bne LBB3_2
; THUMB-DISABLE-NEXT: @ %bb.3: @ %for.end
; THUMB-DISABLE-NEXT: lsls r0, r0, #3
; THUMB-DISABLE-NEXT: @ InlineAsm Start
; THUMB-DISABLE-NEXT: nop
; THUMB-DISABLE-NEXT: @ InlineAsm End
; THUMB-DISABLE-NEXT: pop {r4, r7, pc}
; THUMB-DISABLE-NEXT: LBB3_4: @ %if.else
; THUMB-DISABLE-NEXT: lsls r0, r1, #1
; THUMB-DISABLE-NEXT: pop {r4, r7, pc}
[ARM] Make the frame lowering code ready for shrink-wrapping. Shrink-wrapping can now be tested on ARM with -enable-shrink-wrap. Related to <rdar://problem/20821730> llvm-svn: 242908
2015-07-23 00:34:37 +08:00
entry:
%tobool = icmp eq i32 %cond, 0
br i1 %tobool, label %if.else, label %for.preheader
for.preheader:
tail call void asm "nop", ""()
br label %for.body
for.body: ; preds = %entry, %for.body
%i.05 = phi i32 [ %inc, %for.body ], [ 0, %for.preheader ]
%sum.04 = phi i32 [ %add, %for.body ], [ 0, %for.preheader ]
%call = tail call i32 asm sideeffect "mov $0, #1", "=r,~{r4}"()
%add = add nsw i32 %call, %sum.04
%inc = add nuw nsw i32 %i.05, 1
%exitcond = icmp eq i32 %inc, 10
br i1 %exitcond, label %for.end, label %for.body
for.end: ; preds = %for.body
tail call void asm "nop", "~{r4}"()
%shl = shl i32 %add, 3
br label %if.end
if.else: ; preds = %entry
%mul = shl nsw i32 %N, 1
br label %if.end
if.end: ; preds = %if.else, %for.end
%sum.1 = phi i32 [ %shl, %for.end ], [ %mul, %if.else ]
ret i32 %sum.1
}
declare void @somethingElse(...)
; Check with a more complex case that we do not have restore within the loop and
; save outside.
[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; loopInfoRestoreOutsideLoop:
[ARM] Make the frame lowering code ready for shrink-wrapping. Shrink-wrapping can now be tested on ARM with -enable-shrink-wrap. Related to <rdar://problem/20821730> llvm-svn: 242908
2015-07-23 00:34:37 +08:00
;
[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; cmp r0, #0
; beq [[ELSE_LABEL:LBB[0-9_]+]]
; cbz r0, [[ELSE_LABEL:LBB[0-9_]+]]
[ARM] Make the frame lowering code ready for shrink-wrapping. Shrink-wrapping can now be tested on ARM with -enable-shrink-wrap. Related to <rdar://problem/20821730> llvm-svn: 242908
2015-07-23 00:34:37 +08:00
;
; Prologue code.
; Make sure we save the CSR used in the inline asm: r4.
[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; push {r4, r7, lr}
; add r7, sp, #4
[ARM] Make the frame lowering code ready for shrink-wrapping. Shrink-wrapping can now be tested on ARM with -enable-shrink-wrap. Related to <rdar://problem/20821730> llvm-svn: 242908
2015-07-23 00:34:37 +08:00
;
[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; cmp r0, #0
; beq [[ELSE_LABEL:LBB[0-9_]+]]
; cbz r0, [[ELSE_LABEL:LBB[0-9_]+]]
[ARM] Make the frame lowering code ready for shrink-wrapping. Shrink-wrapping can now be tested on ARM with -enable-shrink-wrap. Related to <rdar://problem/20821730> llvm-svn: 242908
2015-07-23 00:34:37 +08:00
;
; SUM is in r0 because it is coalesced with the second
; argument on the else path.
[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; mov{{s?}} [[SUM:r0]], #0
; mov{{s?}} [[IV:r[0-9]+]], #10
[ARM] Make the frame lowering code ready for shrink-wrapping. Shrink-wrapping can now be tested on ARM with -enable-shrink-wrap. Related to <rdar://problem/20821730> llvm-svn: 242908
2015-07-23 00:34:37 +08:00
;
; Next BB.
[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; [[LOOP:LBB[0-9_]+]]: @ %for.body
; mov{{(\.w)?}} [[TMP:r[0-9]+]], #1
; add [[SUM]], [[TMP]], [[SUM]]
; add [[SUM]], [[TMP]]
; subs [[IV]], [[IV]], #1
; subs [[IV]], #1
; bne [[LOOP]]
[ARM] Make the frame lowering code ready for shrink-wrapping. Shrink-wrapping can now be tested on ARM with -enable-shrink-wrap. Related to <rdar://problem/20821730> llvm-svn: 242908
2015-07-23 00:34:37 +08:00
;
; Next BB.
; SUM << 3.
[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; lsl{{s?}} [[SUM]], [[SUM]], #3
; pop {r4, r7, pc}
[ARM] Make the frame lowering code ready for shrink-wrapping. Shrink-wrapping can now be tested on ARM with -enable-shrink-wrap. Related to <rdar://problem/20821730> llvm-svn: 242908
2015-07-23 00:34:37 +08:00
;
; Duplicated epilogue.
[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; pop {r4, r7, pc}
[ARM] Make the frame lowering code ready for shrink-wrapping. Shrink-wrapping can now be tested on ARM with -enable-shrink-wrap. Related to <rdar://problem/20821730> llvm-svn: 242908
2015-07-23 00:34:37 +08:00
;
[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; [[ELSE_LABEL]]: @ %if.else
[ARM] Make the frame lowering code ready for shrink-wrapping. Shrink-wrapping can now be tested on ARM with -enable-shrink-wrap. Related to <rdar://problem/20821730> llvm-svn: 242908
2015-07-23 00:34:37 +08:00
; Shift second argument by one and store into returned register.
[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; lsl{{s?}} r0, r1, #1
; pop {r4, r7, pc}
[ARM] Make the frame lowering code ready for shrink-wrapping. Shrink-wrapping can now be tested on ARM with -enable-shrink-wrap. Related to <rdar://problem/20821730> llvm-svn: 242908
2015-07-23 00:34:37 +08:00
;
[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; bx lr
Reapply ARM: Do not spill CSR to stack on entry to noreturn functions Should fix UBSan bot by also checking there's no "uwtable" attribute before skipping. Otherwise the unwind table will be useless since its moves expect CSRs to actually be preserved. A noreturn nounwind function can be expected to never return in any way, and by never returning it will also never have to restore any callee-saved registers for its caller. This makes it possible to skip spills of those registers during function entry, saving some stack space and time in the process. This is rather useful for embedded targets with limited stack space. Should fix PR9970. Patch mostly by myeisha (pmb). llvm-svn: 329494
2018-04-07 18:57:03 +08:00
define i32 @loopInfoRestoreOutsideLoop(i32 %cond, i32 %N) "no-frame-pointer-elim"="true" nounwind {
[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; ARM-ENABLE-LABEL: loopInfoRestoreOutsideLoop:
; ARM-ENABLE: @ %bb.0: @ %entry
; ARM-ENABLE-NEXT: cmp r0, #0
; ARM-ENABLE-NEXT: beq LBB4_4
; ARM-ENABLE-NEXT: @ %bb.1: @ %if.then
; ARM-ENABLE-NEXT: push {r4, r7, lr}
; ARM-ENABLE-NEXT: add r7, sp, #4
; ARM-ENABLE-NEXT: mov r0, #0
; ARM-ENABLE-NEXT: mov r1, #10
; ARM-ENABLE-NEXT: @ InlineAsm Start
; ARM-ENABLE-NEXT: nop
; ARM-ENABLE-NEXT: @ InlineAsm End
; ARM-ENABLE-NEXT: LBB4_2: @ %for.body
; ARM-ENABLE-NEXT: @ =>This Inner Loop Header: Depth=1
; ARM-ENABLE-NEXT: @ InlineAsm Start
; ARM-ENABLE-NEXT: mov r2, #1
; ARM-ENABLE-NEXT: @ InlineAsm End
; ARM-ENABLE-NEXT: add r0, r2, r0
; ARM-ENABLE-NEXT: subs r1, r1, #1
; ARM-ENABLE-NEXT: bne LBB4_2
; ARM-ENABLE-NEXT: @ %bb.3: @ %for.end
; ARM-ENABLE-NEXT: lsl r0, r0, #3
; ARM-ENABLE-NEXT: pop {r4, r7, pc}
; ARM-ENABLE-NEXT: LBB4_4: @ %if.else
; ARM-ENABLE-NEXT: lsl r0, r1, #1
; ARM-ENABLE-NEXT: bx lr
;
; ARM-DISABLE-LABEL: loopInfoRestoreOutsideLoop:
; ARM-DISABLE: @ %bb.0: @ %entry
; ARM-DISABLE-NEXT: push {r4, r7, lr}
; ARM-DISABLE-NEXT: add r7, sp, #4
; ARM-DISABLE-NEXT: cmp r0, #0
; ARM-DISABLE-NEXT: beq LBB4_4
; ARM-DISABLE-NEXT: @ %bb.1: @ %if.then
; ARM-DISABLE-NEXT: mov r0, #0
; ARM-DISABLE-NEXT: mov r1, #10
; ARM-DISABLE-NEXT: @ InlineAsm Start
; ARM-DISABLE-NEXT: nop
; ARM-DISABLE-NEXT: @ InlineAsm End
; ARM-DISABLE-NEXT: LBB4_2: @ %for.body
; ARM-DISABLE-NEXT: @ =>This Inner Loop Header: Depth=1
; ARM-DISABLE-NEXT: @ InlineAsm Start
; ARM-DISABLE-NEXT: mov r2, #1
; ARM-DISABLE-NEXT: @ InlineAsm End
; ARM-DISABLE-NEXT: add r0, r2, r0
; ARM-DISABLE-NEXT: subs r1, r1, #1
; ARM-DISABLE-NEXT: bne LBB4_2
; ARM-DISABLE-NEXT: @ %bb.3: @ %for.end
; ARM-DISABLE-NEXT: lsl r0, r0, #3
; ARM-DISABLE-NEXT: pop {r4, r7, pc}
; ARM-DISABLE-NEXT: LBB4_4: @ %if.else
; ARM-DISABLE-NEXT: lsl r0, r1, #1
; ARM-DISABLE-NEXT: pop {r4, r7, pc}
;
; THUMB-ENABLE-LABEL: loopInfoRestoreOutsideLoop:
; THUMB-ENABLE: @ %bb.0: @ %entry
; THUMB-ENABLE-NEXT: cbz r0, LBB4_4
; THUMB-ENABLE-NEXT: @ %bb.1: @ %if.then
; THUMB-ENABLE-NEXT: push {r4, r7, lr}
; THUMB-ENABLE-NEXT: add r7, sp, #4
; THUMB-ENABLE-NEXT: movs r0, #0
; THUMB-ENABLE-NEXT: movs r1, #10
; THUMB-ENABLE-NEXT: @ InlineAsm Start
; THUMB-ENABLE-NEXT: nop
; THUMB-ENABLE-NEXT: @ InlineAsm End
; THUMB-ENABLE-NEXT: LBB4_2: @ %for.body
; THUMB-ENABLE-NEXT: @ =>This Inner Loop Header: Depth=1
; THUMB-ENABLE-NEXT: @ InlineAsm Start
; THUMB-ENABLE-NEXT: mov.w r2, #1
; THUMB-ENABLE-NEXT: @ InlineAsm End
; THUMB-ENABLE-NEXT: add r0, r2
; THUMB-ENABLE-NEXT: subs r1, #1
; THUMB-ENABLE-NEXT: bne LBB4_2
; THUMB-ENABLE-NEXT: @ %bb.3: @ %for.end
; THUMB-ENABLE-NEXT: lsls r0, r0, #3
; THUMB-ENABLE-NEXT: pop {r4, r7, pc}
; THUMB-ENABLE-NEXT: LBB4_4: @ %if.else
; THUMB-ENABLE-NEXT: lsls r0, r1, #1
; THUMB-ENABLE-NEXT: bx lr
;
; THUMB-DISABLE-LABEL: loopInfoRestoreOutsideLoop:
; THUMB-DISABLE: @ %bb.0: @ %entry
; THUMB-DISABLE-NEXT: push {r4, r7, lr}
; THUMB-DISABLE-NEXT: add r7, sp, #4
; THUMB-DISABLE-NEXT: cbz r0, LBB4_4
; THUMB-DISABLE-NEXT: @ %bb.1: @ %if.then
; THUMB-DISABLE-NEXT: movs r0, #0
; THUMB-DISABLE-NEXT: movs r1, #10
; THUMB-DISABLE-NEXT: @ InlineAsm Start
; THUMB-DISABLE-NEXT: nop
; THUMB-DISABLE-NEXT: @ InlineAsm End
; THUMB-DISABLE-NEXT: LBB4_2: @ %for.body
; THUMB-DISABLE-NEXT: @ =>This Inner Loop Header: Depth=1
; THUMB-DISABLE-NEXT: @ InlineAsm Start
; THUMB-DISABLE-NEXT: mov.w r2, #1
; THUMB-DISABLE-NEXT: @ InlineAsm End
; THUMB-DISABLE-NEXT: add r0, r2
; THUMB-DISABLE-NEXT: subs r1, #1
; THUMB-DISABLE-NEXT: bne LBB4_2
; THUMB-DISABLE-NEXT: @ %bb.3: @ %for.end
; THUMB-DISABLE-NEXT: lsls r0, r0, #3
; THUMB-DISABLE-NEXT: pop {r4, r7, pc}
; THUMB-DISABLE-NEXT: LBB4_4: @ %if.else
; THUMB-DISABLE-NEXT: lsls r0, r1, #1
; THUMB-DISABLE-NEXT: pop {r4, r7, pc}
[ARM] Make the frame lowering code ready for shrink-wrapping. Shrink-wrapping can now be tested on ARM with -enable-shrink-wrap. Related to <rdar://problem/20821730> llvm-svn: 242908
2015-07-23 00:34:37 +08:00
entry:
%tobool = icmp eq i32 %cond, 0
br i1 %tobool, label %if.else, label %if.then
if.then: ; preds = %entry
tail call void asm "nop", "~{r4}"()
br label %for.body
for.body: ; preds = %for.body, %if.then
%i.05 = phi i32 [ 0, %if.then ], [ %inc, %for.body ]
%sum.04 = phi i32 [ 0, %if.then ], [ %add, %for.body ]
%call = tail call i32 asm sideeffect "mov $0, #1", "=r,~{r4}"()
%add = add nsw i32 %call, %sum.04
%inc = add nuw nsw i32 %i.05, 1
%exitcond = icmp eq i32 %inc, 10
br i1 %exitcond, label %for.end, label %for.body
for.end: ; preds = %for.body
%shl = shl i32 %add, 3
br label %if.end
if.else: ; preds = %entry
%mul = shl nsw i32 %N, 1
br label %if.end
if.end: ; preds = %if.else, %for.end
%sum.1 = phi i32 [ %shl, %for.end ], [ %mul, %if.else ]
ret i32 %sum.1
}
; Check that we handle function with no frame information correctly.
[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; emptyFrame:
; @ %entry
; mov{{s?}} r0, #0
; bx lr
[ARM] Make the frame lowering code ready for shrink-wrapping. Shrink-wrapping can now be tested on ARM with -enable-shrink-wrap. Related to <rdar://problem/20821730> llvm-svn: 242908
2015-07-23 00:34:37 +08:00
define i32 @emptyFrame() {
[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; ARM-LABEL: emptyFrame:
; ARM: @ %bb.0: @ %entry
; ARM-NEXT: mov r0, #0
; ARM-NEXT: bx lr
;
; THUMB-LABEL: emptyFrame:
; THUMB: @ %bb.0: @ %entry
; THUMB-NEXT: movs r0, #0
; THUMB-NEXT: bx lr
; ARM-ENABLE-LABEL: emptyFrame:
; ARM-ENABLE: @ %bb.0: @ %entry
; ARM-ENABLE-NEXT: mov r0, #0
; ARM-ENABLE-NEXT: bx lr
;
; ARM-DISABLE-LABEL: emptyFrame:
; ARM-DISABLE: @ %bb.0: @ %entry
; ARM-DISABLE-NEXT: mov r0, #0
; ARM-DISABLE-NEXT: bx lr
;
; THUMB-ENABLE-LABEL: emptyFrame:
; THUMB-ENABLE: @ %bb.0: @ %entry
; THUMB-ENABLE-NEXT: movs r0, #0
; THUMB-ENABLE-NEXT: bx lr
;
; THUMB-DISABLE-LABEL: emptyFrame:
; THUMB-DISABLE: @ %bb.0: @ %entry
; THUMB-DISABLE-NEXT: movs r0, #0
; THUMB-DISABLE-NEXT: bx lr
[ARM] Make the frame lowering code ready for shrink-wrapping. Shrink-wrapping can now be tested on ARM with -enable-shrink-wrap. Related to <rdar://problem/20821730> llvm-svn: 242908
2015-07-23 00:34:37 +08:00
entry:
ret i32 0
}
; Check that we handle inline asm correctly.
[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; inlineAsm:
[ARM] Make the frame lowering code ready for shrink-wrapping. Shrink-wrapping can now be tested on ARM with -enable-shrink-wrap. Related to <rdar://problem/20821730> llvm-svn: 242908
2015-07-23 00:34:37 +08:00
;
[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; cmp r0, #0
; beq [[ELSE_LABEL:LBB[0-9_]+]]
; cbz r0, [[ELSE_LABEL:LBB[0-9_]+]]
[ARM] Make the frame lowering code ready for shrink-wrapping. Shrink-wrapping can now be tested on ARM with -enable-shrink-wrap. Related to <rdar://problem/20821730> llvm-svn: 242908
2015-07-23 00:34:37 +08:00
;
; Prologue code.
; Make sure we save the CSR used in the inline asm: r4.
[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; push {r4, r7, lr}
; add r7, sp, #4
[ARM] Make the frame lowering code ready for shrink-wrapping. Shrink-wrapping can now be tested on ARM with -enable-shrink-wrap. Related to <rdar://problem/20821730> llvm-svn: 242908
2015-07-23 00:34:37 +08:00
;
[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; cmp r0, #0
; beq [[ELSE_LABEL:LBB[0-9_]+]]
; cbz r0, [[ELSE_LABEL:LBB[0-9_]+]]
[ARM] Make the frame lowering code ready for shrink-wrapping. Shrink-wrapping can now be tested on ARM with -enable-shrink-wrap. Related to <rdar://problem/20821730> llvm-svn: 242908
2015-07-23 00:34:37 +08:00
;
[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; mov{{s?}} [[IV:r[0-9]+]], #10
[ARM] Make the frame lowering code ready for shrink-wrapping. Shrink-wrapping can now be tested on ARM with -enable-shrink-wrap. Related to <rdar://problem/20821730> llvm-svn: 242908
2015-07-23 00:34:37 +08:00
;
; Next BB.
[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; [[LOOP:LBB[0-9_]+]]: @ %for.body
; subs [[IV]], [[IV]], #1
; subs [[IV]], #1
; add{{(\.w)?}} r4, r4, #1
; bne [[LOOP]]
[ARM] Make the frame lowering code ready for shrink-wrapping. Shrink-wrapping can now be tested on ARM with -enable-shrink-wrap. Related to <rdar://problem/20821730> llvm-svn: 242908
2015-07-23 00:34:37 +08:00
;
; Next BB.
[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; mov{{s?}} r0, #0
[ARM] Make the frame lowering code ready for shrink-wrapping. Shrink-wrapping can now be tested on ARM with -enable-shrink-wrap. Related to <rdar://problem/20821730> llvm-svn: 242908
2015-07-23 00:34:37 +08:00
;
; Duplicated epilogue.
[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; pop {r4, r7, pc}
[ARM] Make the frame lowering code ready for shrink-wrapping. Shrink-wrapping can now be tested on ARM with -enable-shrink-wrap. Related to <rdar://problem/20821730> llvm-svn: 242908
2015-07-23 00:34:37 +08:00
;
[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; [[ELSE_LABEL]]: @ %if.else
[ARM] Make the frame lowering code ready for shrink-wrapping. Shrink-wrapping can now be tested on ARM with -enable-shrink-wrap. Related to <rdar://problem/20821730> llvm-svn: 242908
2015-07-23 00:34:37 +08:00
; Shift second argument by one and store into returned register.
[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; lsl{{s?}} r0, r1, #1
; pop {r4, r7, pc}
[ARM] Make the frame lowering code ready for shrink-wrapping. Shrink-wrapping can now be tested on ARM with -enable-shrink-wrap. Related to <rdar://problem/20821730> llvm-svn: 242908
2015-07-23 00:34:37 +08:00
;
[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; bx lr
[ARM] Generate consistent frame records for Thumb2 There is not an official documented ABI for frame pointers in Thumb2, but we should try to emit something which is useful. We use r7 as the frame pointer for Thumb code, which currently means that if a function needs to save a high register (r8-r11), it will get pushed to the stack between the frame pointer (r7) and link register (r14). This means that while a stack unwinder can follow the chain of frame pointers up the stack, it cannot know the offset to lr, so does not know which functions correspond to the stack frames. To fix this, we need to push the callee-saved registers in two batches, with the first push saving the low registers, fp and lr, and the second push saving the high registers. This is already implemented, but previously only used for iOS. This patch turns it on for all Thumb2 targets when frame pointers are required by the ABI, and the frame pointer is r7 (Windows uses r11, so this isn't a problem there). If frame pointer elimination is enabled we still emit a single push/pop even if we need a frame pointer for other reasons, to avoid increasing code size. We must also ensure that lr is pushed to the stack when using a frame pointer, so that we end up with a complete frame record. Situations that could cause this were rare, because we already push lr in most situations so that we can return using the pop instruction. Differential Revision: https://reviews.llvm.org/D23516 llvm-svn: 279506
2016-08-23 17:19:22 +08:00
define i32 @inlineAsm(i32 %cond, i32 %N) "no-frame-pointer-elim"="true" {
[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; ARM-ENABLE-LABEL: inlineAsm:
; ARM-ENABLE: @ %bb.0: @ %entry
; ARM-ENABLE-NEXT: cmp r0, #0
; ARM-ENABLE-NEXT: beq LBB6_4
; ARM-ENABLE-NEXT: @ %bb.1: @ %for.preheader
; ARM-ENABLE-NEXT: push {r4, r7, lr}
; ARM-ENABLE-NEXT: add r7, sp, #4
; ARM-ENABLE-NEXT: mov r0, #10
; ARM-ENABLE-NEXT: @ InlineAsm Start
; ARM-ENABLE-NEXT: nop
; ARM-ENABLE-NEXT: @ InlineAsm End
; ARM-ENABLE-NEXT: LBB6_2: @ %for.body
; ARM-ENABLE-NEXT: @ =>This Inner Loop Header: Depth=1
; ARM-ENABLE-NEXT: subs r0, r0, #1
; ARM-ENABLE-NEXT: @ InlineAsm Start
; ARM-ENABLE-NEXT: add r4, r4, #1
; ARM-ENABLE-NEXT: @ InlineAsm End
; ARM-ENABLE-NEXT: bne LBB6_2
; ARM-ENABLE-NEXT: @ %bb.3: @ %for.exit
; ARM-ENABLE-NEXT: mov r0, #0
; ARM-ENABLE-NEXT: @ InlineAsm Start
; ARM-ENABLE-NEXT: nop
; ARM-ENABLE-NEXT: @ InlineAsm End
; ARM-ENABLE-NEXT: pop {r4, r7, pc}
; ARM-ENABLE-NEXT: LBB6_4: @ %if.else
; ARM-ENABLE-NEXT: lsl r0, r1, #1
; ARM-ENABLE-NEXT: bx lr
;
; ARM-DISABLE-LABEL: inlineAsm:
; ARM-DISABLE: @ %bb.0: @ %entry
; ARM-DISABLE-NEXT: push {r4, r7, lr}
; ARM-DISABLE-NEXT: add r7, sp, #4
; ARM-DISABLE-NEXT: cmp r0, #0
; ARM-DISABLE-NEXT: beq LBB6_4
; ARM-DISABLE-NEXT: @ %bb.1: @ %for.preheader
; ARM-DISABLE-NEXT: mov r0, #10
; ARM-DISABLE-NEXT: @ InlineAsm Start
; ARM-DISABLE-NEXT: nop
; ARM-DISABLE-NEXT: @ InlineAsm End
; ARM-DISABLE-NEXT: LBB6_2: @ %for.body
; ARM-DISABLE-NEXT: @ =>This Inner Loop Header: Depth=1
; ARM-DISABLE-NEXT: subs r0, r0, #1
; ARM-DISABLE-NEXT: @ InlineAsm Start
; ARM-DISABLE-NEXT: add r4, r4, #1
; ARM-DISABLE-NEXT: @ InlineAsm End
; ARM-DISABLE-NEXT: bne LBB6_2
; ARM-DISABLE-NEXT: @ %bb.3: @ %for.exit
; ARM-DISABLE-NEXT: mov r0, #0
; ARM-DISABLE-NEXT: @ InlineAsm Start
; ARM-DISABLE-NEXT: nop
; ARM-DISABLE-NEXT: @ InlineAsm End
; ARM-DISABLE-NEXT: pop {r4, r7, pc}
; ARM-DISABLE-NEXT: LBB6_4: @ %if.else
; ARM-DISABLE-NEXT: lsl r0, r1, #1
; ARM-DISABLE-NEXT: pop {r4, r7, pc}
;
; THUMB-ENABLE-LABEL: inlineAsm:
; THUMB-ENABLE: @ %bb.0: @ %entry
; THUMB-ENABLE-NEXT: cbz r0, LBB6_4
; THUMB-ENABLE-NEXT: @ %bb.1: @ %for.preheader
; THUMB-ENABLE-NEXT: push {r4, r7, lr}
; THUMB-ENABLE-NEXT: add r7, sp, #4
; THUMB-ENABLE-NEXT: movs r0, #10
; THUMB-ENABLE-NEXT: @ InlineAsm Start
; THUMB-ENABLE-NEXT: nop
; THUMB-ENABLE-NEXT: @ InlineAsm End
; THUMB-ENABLE-NEXT: LBB6_2: @ %for.body
; THUMB-ENABLE-NEXT: @ =>This Inner Loop Header: Depth=1
; THUMB-ENABLE-NEXT: subs r0, #1
; THUMB-ENABLE-NEXT: @ InlineAsm Start
; THUMB-ENABLE-NEXT: add.w r4, r4, #1
; THUMB-ENABLE-NEXT: @ InlineAsm End
; THUMB-ENABLE-NEXT: bne LBB6_2
; THUMB-ENABLE-NEXT: @ %bb.3: @ %for.exit
; THUMB-ENABLE-NEXT: movs r0, #0
; THUMB-ENABLE-NEXT: @ InlineAsm Start
; THUMB-ENABLE-NEXT: nop
; THUMB-ENABLE-NEXT: @ InlineAsm End
; THUMB-ENABLE-NEXT: pop {r4, r7, pc}
; THUMB-ENABLE-NEXT: LBB6_4: @ %if.else
; THUMB-ENABLE-NEXT: lsls r0, r1, #1
; THUMB-ENABLE-NEXT: bx lr
;
; THUMB-DISABLE-LABEL: inlineAsm:
; THUMB-DISABLE: @ %bb.0: @ %entry
; THUMB-DISABLE-NEXT: push {r4, r7, lr}
; THUMB-DISABLE-NEXT: add r7, sp, #4
; THUMB-DISABLE-NEXT: cbz r0, LBB6_4
; THUMB-DISABLE-NEXT: @ %bb.1: @ %for.preheader
; THUMB-DISABLE-NEXT: movs r0, #10
; THUMB-DISABLE-NEXT: @ InlineAsm Start
; THUMB-DISABLE-NEXT: nop
; THUMB-DISABLE-NEXT: @ InlineAsm End
; THUMB-DISABLE-NEXT: LBB6_2: @ %for.body
; THUMB-DISABLE-NEXT: @ =>This Inner Loop Header: Depth=1
; THUMB-DISABLE-NEXT: subs r0, #1
; THUMB-DISABLE-NEXT: @ InlineAsm Start
; THUMB-DISABLE-NEXT: add.w r4, r4, #1
; THUMB-DISABLE-NEXT: @ InlineAsm End
; THUMB-DISABLE-NEXT: bne LBB6_2
; THUMB-DISABLE-NEXT: @ %bb.3: @ %for.exit
; THUMB-DISABLE-NEXT: movs r0, #0
; THUMB-DISABLE-NEXT: @ InlineAsm Start
; THUMB-DISABLE-NEXT: nop
; THUMB-DISABLE-NEXT: @ InlineAsm End
; THUMB-DISABLE-NEXT: pop {r4, r7, pc}
; THUMB-DISABLE-NEXT: LBB6_4: @ %if.else
; THUMB-DISABLE-NEXT: lsls r0, r1, #1
; THUMB-DISABLE-NEXT: pop {r4, r7, pc}
[ARM] Make the frame lowering code ready for shrink-wrapping. Shrink-wrapping can now be tested on ARM with -enable-shrink-wrap. Related to <rdar://problem/20821730> llvm-svn: 242908
2015-07-23 00:34:37 +08:00
entry:
%tobool = icmp eq i32 %cond, 0
br i1 %tobool, label %if.else, label %for.preheader
for.preheader:
tail call void asm "nop", ""()
br label %for.body
for.body: ; preds = %entry, %for.body
%i.03 = phi i32 [ %inc, %for.body ], [ 0, %for.preheader ]
tail call void asm sideeffect "add r4, #1", "~{r4}"()
%inc = add nuw nsw i32 %i.03, 1
%exitcond = icmp eq i32 %inc, 10
br i1 %exitcond, label %for.exit, label %for.body
for.exit:
tail call void asm "nop", ""()
br label %if.end
if.else: ; preds = %entry
%mul = shl nsw i32 %N, 1
br label %if.end
if.end: ; preds = %for.body, %if.else
%sum.0 = phi i32 [ %mul, %if.else ], [ 0, %for.exit ]
ret i32 %sum.0
}
; Check that we handle calls to variadic functions correctly.
[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; callVariadicFunc:
[ARM] Make the frame lowering code ready for shrink-wrapping. Shrink-wrapping can now be tested on ARM with -enable-shrink-wrap. Related to <rdar://problem/20821730> llvm-svn: 242908
2015-07-23 00:34:37 +08:00
;
[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; cmp r0, #0
; beq [[ELSE_LABEL:LBB[0-9_]+]]
; cbz r0, [[ELSE_LABEL:LBB[0-9_]+]]
[ARM] Make the frame lowering code ready for shrink-wrapping. Shrink-wrapping can now be tested on ARM with -enable-shrink-wrap. Related to <rdar://problem/20821730> llvm-svn: 242908
2015-07-23 00:34:37 +08:00
;
; Prologue code.
[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; push {r7, lr}
; mov r7, sp
; sub sp, {{(sp, )?}}#12
[ARM] Make the frame lowering code ready for shrink-wrapping. Shrink-wrapping can now be tested on ARM with -enable-shrink-wrap. Related to <rdar://problem/20821730> llvm-svn: 242908
2015-07-23 00:34:37 +08:00
;
[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; cmp r0, #0
; beq [[ELSE_LABEL:LBB[0-9_]+]]
; cbz r0, [[ELSE_LABEL:LBB[0-9_]+]]
[ARM] Make the frame lowering code ready for shrink-wrapping. Shrink-wrapping can now be tested on ARM with -enable-shrink-wrap. Related to <rdar://problem/20821730> llvm-svn: 242908
2015-07-23 00:34:37 +08:00
;
; Setup of the varags.
[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; mov r0, r1
; mov r2, r1
; mov r3, r1
; str r1, [sp]
; str r1, [sp, #4]
; strd r1, r1, [sp]
; str r1, [sp, #8]
; bl{{x?}} _someVariadicFunc
; lsl{{s?}} r0, r0, #3
; mov sp, r7
; add sp, #12
; pop {r7, pc}
;
; [[ELSE_LABEL]]: @ %if.else
[ARM] Make the frame lowering code ready for shrink-wrapping. Shrink-wrapping can now be tested on ARM with -enable-shrink-wrap. Related to <rdar://problem/20821730> llvm-svn: 242908
2015-07-23 00:34:37 +08:00
; Shift second argument by one and store into returned register.
[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; lsl{{s?}} r0, r1, #1
[ARM] Make the frame lowering code ready for shrink-wrapping. Shrink-wrapping can now be tested on ARM with -enable-shrink-wrap. Related to <rdar://problem/20821730> llvm-svn: 242908
2015-07-23 00:34:37 +08:00
;
; Epilogue code.
[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; bx lr
[ARM] Make the frame lowering code ready for shrink-wrapping. Shrink-wrapping can now be tested on ARM with -enable-shrink-wrap. Related to <rdar://problem/20821730> llvm-svn: 242908
2015-07-23 00:34:37 +08:00
;
[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; mov sp, r7
; add sp, #12
; pop {r7, pc}
[ARM] Generate consistent frame records for Thumb2 There is not an official documented ABI for frame pointers in Thumb2, but we should try to emit something which is useful. We use r7 as the frame pointer for Thumb code, which currently means that if a function needs to save a high register (r8-r11), it will get pushed to the stack between the frame pointer (r7) and link register (r14). This means that while a stack unwinder can follow the chain of frame pointers up the stack, it cannot know the offset to lr, so does not know which functions correspond to the stack frames. To fix this, we need to push the callee-saved registers in two batches, with the first push saving the low registers, fp and lr, and the second push saving the high registers. This is already implemented, but previously only used for iOS. This patch turns it on for all Thumb2 targets when frame pointers are required by the ABI, and the frame pointer is r7 (Windows uses r11, so this isn't a problem there). If frame pointer elimination is enabled we still emit a single push/pop even if we need a frame pointer for other reasons, to avoid increasing code size. We must also ensure that lr is pushed to the stack when using a frame pointer, so that we end up with a complete frame record. Situations that could cause this were rare, because we already push lr in most situations so that we can return using the pop instruction. Differential Revision: https://reviews.llvm.org/D23516 llvm-svn: 279506
2016-08-23 17:19:22 +08:00
define i32 @callVariadicFunc(i32 %cond, i32 %N) "no-frame-pointer-elim"="true" {
[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; ARM-ENABLE-LABEL: callVariadicFunc:
; ARM-ENABLE: @ %bb.0: @ %entry
; ARM-ENABLE-NEXT: cmp r0, #0
; ARM-ENABLE-NEXT: beq LBB7_2
; ARM-ENABLE-NEXT: @ %bb.1: @ %if.then
; ARM-ENABLE-NEXT: push {r7, lr}
; ARM-ENABLE-NEXT: mov r7, sp
; ARM-ENABLE-NEXT: sub sp, sp, #12
; ARM-ENABLE-NEXT: mov r0, r1
; ARM-ENABLE-NEXT: mov r2, r1
; ARM-ENABLE-NEXT: mov r3, r1
; ARM-ENABLE-NEXT: str r1, [sp]
; ARM-ENABLE-NEXT: str r1, [sp, #4]
; ARM-ENABLE-NEXT: str r1, [sp, #8]
; ARM-ENABLE-NEXT: bl _someVariadicFunc
; ARM-ENABLE-NEXT: lsl r0, r0, #3
; ARM-ENABLE-NEXT: mov sp, r7
; ARM-ENABLE-NEXT: pop {r7, pc}
; ARM-ENABLE-NEXT: LBB7_2: @ %if.else
; ARM-ENABLE-NEXT: lsl r0, r1, #1
; ARM-ENABLE-NEXT: bx lr
;
; ARM-DISABLE-LABEL: callVariadicFunc:
; ARM-DISABLE: @ %bb.0: @ %entry
; ARM-DISABLE-NEXT: push {r7, lr}
; ARM-DISABLE-NEXT: mov r7, sp
; ARM-DISABLE-NEXT: sub sp, sp, #12
; ARM-DISABLE-NEXT: cmp r0, #0
; ARM-DISABLE-NEXT: beq LBB7_2
; ARM-DISABLE-NEXT: @ %bb.1: @ %if.then
; ARM-DISABLE-NEXT: mov r0, r1
; ARM-DISABLE-NEXT: mov r2, r1
; ARM-DISABLE-NEXT: mov r3, r1
; ARM-DISABLE-NEXT: str r1, [sp]
; ARM-DISABLE-NEXT: str r1, [sp, #4]
; ARM-DISABLE-NEXT: str r1, [sp, #8]
; ARM-DISABLE-NEXT: bl _someVariadicFunc
; ARM-DISABLE-NEXT: lsl r0, r0, #3
; ARM-DISABLE-NEXT: mov sp, r7
; ARM-DISABLE-NEXT: pop {r7, pc}
; ARM-DISABLE-NEXT: LBB7_2: @ %if.else
; ARM-DISABLE-NEXT: lsl r0, r1, #1
; ARM-DISABLE-NEXT: mov sp, r7
; ARM-DISABLE-NEXT: pop {r7, pc}
;
; THUMB-ENABLE-LABEL: callVariadicFunc:
; THUMB-ENABLE: @ %bb.0: @ %entry
; THUMB-ENABLE-NEXT: cbz r0, LBB7_2
; THUMB-ENABLE-NEXT: @ %bb.1: @ %if.then
; THUMB-ENABLE-NEXT: push {r7, lr}
; THUMB-ENABLE-NEXT: mov r7, sp
; THUMB-ENABLE-NEXT: sub sp, #12
; THUMB-ENABLE-NEXT: mov r0, r1
; THUMB-ENABLE-NEXT: mov r2, r1
; THUMB-ENABLE-NEXT: mov r3, r1
; THUMB-ENABLE-NEXT: strd r1, r1, [sp]
; THUMB-ENABLE-NEXT: str r1, [sp, #8]
; THUMB-ENABLE-NEXT: bl _someVariadicFunc
; THUMB-ENABLE-NEXT: lsls r0, r0, #3
; THUMB-ENABLE-NEXT: add sp, #12
; THUMB-ENABLE-NEXT: pop {r7, pc}
; THUMB-ENABLE-NEXT: LBB7_2: @ %if.else
; THUMB-ENABLE-NEXT: lsls r0, r1, #1
; THUMB-ENABLE-NEXT: bx lr
;
; THUMB-DISABLE-LABEL: callVariadicFunc:
; THUMB-DISABLE: @ %bb.0: @ %entry
; THUMB-DISABLE-NEXT: push {r7, lr}
; THUMB-DISABLE-NEXT: mov r7, sp
; THUMB-DISABLE-NEXT: sub sp, #12
; THUMB-DISABLE-NEXT: cbz r0, LBB7_2
; THUMB-DISABLE-NEXT: @ %bb.1: @ %if.then
; THUMB-DISABLE-NEXT: mov r0, r1
; THUMB-DISABLE-NEXT: mov r2, r1
; THUMB-DISABLE-NEXT: mov r3, r1
; THUMB-DISABLE-NEXT: strd r1, r1, [sp]
; THUMB-DISABLE-NEXT: str r1, [sp, #8]
; THUMB-DISABLE-NEXT: bl _someVariadicFunc
; THUMB-DISABLE-NEXT: lsls r0, r0, #3
; THUMB-DISABLE-NEXT: add sp, #12
; THUMB-DISABLE-NEXT: pop {r7, pc}
; THUMB-DISABLE-NEXT: LBB7_2: @ %if.else
; THUMB-DISABLE-NEXT: lsls r0, r1, #1
; THUMB-DISABLE-NEXT: add sp, #12
; THUMB-DISABLE-NEXT: pop {r7, pc}
[ARM] Make the frame lowering code ready for shrink-wrapping. Shrink-wrapping can now be tested on ARM with -enable-shrink-wrap. Related to <rdar://problem/20821730> llvm-svn: 242908
2015-07-23 00:34:37 +08:00
entry:
%tobool = icmp eq i32 %cond, 0
br i1 %tobool, label %if.else, label %if.then
if.then: ; preds = %entry
%call = tail call i32 (i32, ...) @someVariadicFunc(i32 %N, i32 %N, i32 %N, i32 %N, i32 %N, i32 %N, i32 %N)
%shl = shl i32 %call, 3
br label %if.end
if.else: ; preds = %entry
%mul = shl nsw i32 %N, 1
br label %if.end
if.end: ; preds = %if.else, %if.then
%sum.0 = phi i32 [ %shl, %if.then ], [ %mul, %if.else ]
ret i32 %sum.0
}
declare i32 @someVariadicFunc(i32, ...)
; Make sure we do not insert unreachable code after noreturn function.
; Although this is not incorrect to insert such code, it is useless
; and it hurts the binary size.
;
[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; noreturn:
; push
; cmp r0, #0
; cmp r0, #0
; bne [[ABORT:LBB[0-9_]+]]
; bne [[ABORT:LBB[0-9_]+]]
; cbnz r0, [[ABORT:LBB[0-9_]+]]
; cbnz r0, [[ABORT:LBB[0-9_]+]]
DAG: avoid duplicated truncating for sign extended operand Summary: When performing cmp for EQ/NE and the operand is sign extended, we can avoid the truncaton if the bits to be tested are no less than origianl bits. Reviewers: eli.friedman Subscribers: eli.friedman, aemerson, nemanjai, t.p.northover, llvm-commits Differential Revision: https://reviews.llvm.org/D22933 llvm-svn: 277252
2016-07-30 07:33:48 +08:00
[ARM] Make the frame lowering code ready for shrink-wrapping. Shrink-wrapping can now be tested on ARM with -enable-shrink-wrap. Related to <rdar://problem/20821730> llvm-svn: 242908
2015-07-23 00:34:37 +08:00
;
[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; mov{{s?}} r0, #42
[ARM] Make the frame lowering code ready for shrink-wrapping. Shrink-wrapping can now be tested on ARM with -enable-shrink-wrap. Related to <rdar://problem/20821730> llvm-svn: 242908
2015-07-23 00:34:37 +08:00
;
[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; bx lr
[ARM] Make the frame lowering code ready for shrink-wrapping. Shrink-wrapping can now be tested on ARM with -enable-shrink-wrap. Related to <rdar://problem/20821730> llvm-svn: 242908
2015-07-23 00:34:37 +08:00
;
[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; pop
[ARM] Make the frame lowering code ready for shrink-wrapping. Shrink-wrapping can now be tested on ARM with -enable-shrink-wrap. Related to <rdar://problem/20821730> llvm-svn: 242908
2015-07-23 00:34:37 +08:00
;;
[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; [[ABORT]]: @ %if.abort
[ARM] Make the frame lowering code ready for shrink-wrapping. Shrink-wrapping can now be tested on ARM with -enable-shrink-wrap. Related to <rdar://problem/20821730> llvm-svn: 242908
2015-07-23 00:34:37 +08:00
;
[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; push
[ARM] Make the frame lowering code ready for shrink-wrapping. Shrink-wrapping can now be tested on ARM with -enable-shrink-wrap. Related to <rdar://problem/20821730> llvm-svn: 242908
2015-07-23 00:34:37 +08:00
;
[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; bl{{x?}} _abort
; pop
[ARM] Generate consistent frame records for Thumb2 There is not an official documented ABI for frame pointers in Thumb2, but we should try to emit something which is useful. We use r7 as the frame pointer for Thumb code, which currently means that if a function needs to save a high register (r8-r11), it will get pushed to the stack between the frame pointer (r7) and link register (r14). This means that while a stack unwinder can follow the chain of frame pointers up the stack, it cannot know the offset to lr, so does not know which functions correspond to the stack frames. To fix this, we need to push the callee-saved registers in two batches, with the first push saving the low registers, fp and lr, and the second push saving the high registers. This is already implemented, but previously only used for iOS. This patch turns it on for all Thumb2 targets when frame pointers are required by the ABI, and the frame pointer is r7 (Windows uses r11, so this isn't a problem there). If frame pointer elimination is enabled we still emit a single push/pop even if we need a frame pointer for other reasons, to avoid increasing code size. We must also ensure that lr is pushed to the stack when using a frame pointer, so that we end up with a complete frame record. Situations that could cause this were rare, because we already push lr in most situations so that we can return using the pop instruction. Differential Revision: https://reviews.llvm.org/D23516 llvm-svn: 279506
2016-08-23 17:19:22 +08:00
define i32 @noreturn(i8 signext %bad_thing) "no-frame-pointer-elim"="true" {
[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; ARM-ENABLE-LABEL: noreturn:
; ARM-ENABLE: @ %bb.0: @ %entry
; ARM-ENABLE-NEXT: cmp r0, #0
; ARM-ENABLE-NEXT: bne LBB8_2
; ARM-ENABLE-NEXT: @ %bb.1: @ %if.end
; ARM-ENABLE-NEXT: mov r0, #42
; ARM-ENABLE-NEXT: bx lr
; ARM-ENABLE-NEXT: LBB8_2: @ %if.abort
; ARM-ENABLE-NEXT: push {r4, r7, lr}
; ARM-ENABLE-NEXT: add r7, sp, #4
; ARM-ENABLE-NEXT: @ InlineAsm Start
; ARM-ENABLE-NEXT: mov r0, #1
; ARM-ENABLE-NEXT: @ InlineAsm End
; ARM-ENABLE-NEXT: bl _abort
;
; ARM-DISABLE-LABEL: noreturn:
; ARM-DISABLE: @ %bb.0: @ %entry
; ARM-DISABLE-NEXT: push {r4, r7, lr}
; ARM-DISABLE-NEXT: add r7, sp, #4
; ARM-DISABLE-NEXT: cmp r0, #0
; ARM-DISABLE-NEXT: bne LBB8_2
; ARM-DISABLE-NEXT: @ %bb.1: @ %if.end
; ARM-DISABLE-NEXT: mov r0, #42
; ARM-DISABLE-NEXT: pop {r4, r7, pc}
; ARM-DISABLE-NEXT: LBB8_2: @ %if.abort
; ARM-DISABLE-NEXT: @ InlineAsm Start
; ARM-DISABLE-NEXT: mov r0, #1
; ARM-DISABLE-NEXT: @ InlineAsm End
; ARM-DISABLE-NEXT: bl _abort
;
; THUMB-ENABLE-LABEL: noreturn:
; THUMB-ENABLE: @ %bb.0: @ %entry
; THUMB-ENABLE-NEXT: cbnz r0, LBB8_2
; THUMB-ENABLE-NEXT: @ %bb.1: @ %if.end
; THUMB-ENABLE-NEXT: movs r0, #42
; THUMB-ENABLE-NEXT: bx lr
; THUMB-ENABLE-NEXT: LBB8_2: @ %if.abort
; THUMB-ENABLE-NEXT: push {r4, r7, lr}
; THUMB-ENABLE-NEXT: add r7, sp, #4
; THUMB-ENABLE-NEXT: @ InlineAsm Start
; THUMB-ENABLE-NEXT: mov.w r0, #1
; THUMB-ENABLE-NEXT: @ InlineAsm End
; THUMB-ENABLE-NEXT: bl _abort
;
; THUMB-DISABLE-LABEL: noreturn:
; THUMB-DISABLE: @ %bb.0: @ %entry
; THUMB-DISABLE-NEXT: push {r4, r7, lr}
; THUMB-DISABLE-NEXT: add r7, sp, #4
; THUMB-DISABLE-NEXT: cbnz r0, LBB8_2
; THUMB-DISABLE-NEXT: @ %bb.1: @ %if.end
; THUMB-DISABLE-NEXT: movs r0, #42
; THUMB-DISABLE-NEXT: pop {r4, r7, pc}
; THUMB-DISABLE-NEXT: LBB8_2: @ %if.abort
; THUMB-DISABLE-NEXT: @ InlineAsm Start
; THUMB-DISABLE-NEXT: mov.w r0, #1
; THUMB-DISABLE-NEXT: @ InlineAsm End
; THUMB-DISABLE-NEXT: bl _abort
[ARM] Make the frame lowering code ready for shrink-wrapping. Shrink-wrapping can now be tested on ARM with -enable-shrink-wrap. Related to <rdar://problem/20821730> llvm-svn: 242908
2015-07-23 00:34:37 +08:00
entry:
%tobool = icmp eq i8 %bad_thing, 0
br i1 %tobool, label %if.end, label %if.abort
if.abort:
%call = tail call i32 asm sideeffect "mov $0, #1", "=r,~{r4}"()
tail call void @abort() #0
unreachable
if.end:
ret i32 42
}
declare void @abort() #0
attributes #0 = { noreturn nounwind }
Fix possible infinite loop in shrink wrapping when searching for save/restore points. There is an infinite loop that can occur in Shrink Wrapping while searching for the Save/Restore points. Part of this search checks whether the save/restore points are located in different loop nests and if so, uses the (post) dominator trees to find the immediate (post) dominator blocks. However, if the current block does not have any immediate (post) dominators then this search will result in an infinite loop. This can occur in code containing an infinite loop. The modification checks whether the immediate (post) dominator is different from the current save/restore block. If it is not, then the search terminates and the current location is not considered as a valid save/restore point for shrink wrapping. Phabricator: http://reviews.llvm.org/D11607 llvm-svn: 244247
2015-08-07 03:01:57 +08:00
; Make sure that we handle infinite loops properly When checking that the Save
; and Restore blocks are control flow equivalent, the loop searches for the
; immediate (post) dominator for the (restore) save blocks. When either the Save
; or Restore block is located in an infinite loop the only immediate (post)
; dominator is itself. In this case, we cannot perform shrink wrapping, but we
; should return gracefully and continue compilation.
; The only condition for this test is the compilation finishes correctly.
[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; infiniteloop
; pop
[ARM] Generate consistent frame records for Thumb2 There is not an official documented ABI for frame pointers in Thumb2, but we should try to emit something which is useful. We use r7 as the frame pointer for Thumb code, which currently means that if a function needs to save a high register (r8-r11), it will get pushed to the stack between the frame pointer (r7) and link register (r14). This means that while a stack unwinder can follow the chain of frame pointers up the stack, it cannot know the offset to lr, so does not know which functions correspond to the stack frames. To fix this, we need to push the callee-saved registers in two batches, with the first push saving the low registers, fp and lr, and the second push saving the high registers. This is already implemented, but previously only used for iOS. This patch turns it on for all Thumb2 targets when frame pointers are required by the ABI, and the frame pointer is r7 (Windows uses r11, so this isn't a problem there). If frame pointer elimination is enabled we still emit a single push/pop even if we need a frame pointer for other reasons, to avoid increasing code size. We must also ensure that lr is pushed to the stack when using a frame pointer, so that we end up with a complete frame record. Situations that could cause this were rare, because we already push lr in most situations so that we can return using the pop instruction. Differential Revision: https://reviews.llvm.org/D23516 llvm-svn: 279506
2016-08-23 17:19:22 +08:00
define void @infiniteloop() "no-frame-pointer-elim"="true" {
[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; ARM-LABEL: infiniteloop:
; ARM: @ %bb.0: @ %entry
; ARM-NEXT: push {r4, r5, r7, lr}
; ARM-NEXT: add r7, sp, #8
; ARM-NEXT: mov r0, #0
; ARM-NEXT: cmp r0, #0
; ARM-NEXT: bne LBB9_3
; ARM-NEXT: @ %bb.1: @ %if.then
; ARM-NEXT: sub r1, sp, #16
; ARM-NEXT: mov sp, r1
; ARM-NEXT: LBB9_2: @ %for.body
; ARM-NEXT: @ =>This Inner Loop Header: Depth=1
; ARM-NEXT: @ InlineAsm Start
; ARM-NEXT: mov r2, #1
; ARM-NEXT: @ InlineAsm End
; ARM-NEXT: add r0, r2, r0
; ARM-NEXT: str r0, [r1]
; ARM-NEXT: b LBB9_2
; ARM-NEXT: LBB9_3: @ %if.end
; ARM-NEXT: sub sp, r7, #8
; ARM-NEXT: pop {r4, r5, r7, pc}
;
; THUMB-LABEL: infiniteloop:
; THUMB: @ %bb.0: @ %entry
; THUMB-NEXT: push {r4, r5, r7, lr}
; THUMB-NEXT: add r7, sp, #8
; THUMB-NEXT: movs r0, #0
; THUMB-NEXT: cbnz r0, LBB9_3
; THUMB-NEXT: @ %bb.1: @ %if.then
; THUMB-NEXT: sub.w r0, sp, #16
; THUMB-NEXT: mov sp, r0
; THUMB-NEXT: movs r1, #0
; THUMB-NEXT: LBB9_2: @ %for.body
; THUMB-NEXT: @ =>This Inner Loop Header: Depth=1
; THUMB-NEXT: @ InlineAsm Start
; THUMB-NEXT: mov.w r2, #1
; THUMB-NEXT: @ InlineAsm End
; THUMB-NEXT: add r1, r2
; THUMB-NEXT: str r1, [r0]
; THUMB-NEXT: b LBB9_2
; THUMB-NEXT: LBB9_3: @ %if.end
; THUMB-NEXT: sub.w r4, r7, #8
; THUMB-NEXT: mov sp, r4
; THUMB-NEXT: pop {r4, r5, r7, pc}
; ARM-ENABLE-LABEL: infiniteloop:
; ARM-ENABLE: @ %bb.0: @ %entry
; ARM-ENABLE-NEXT: push {r4, r5, r7, lr}
; ARM-ENABLE-NEXT: add r7, sp, #8
; ARM-ENABLE-NEXT: mov r0, #0
; ARM-ENABLE-NEXT: cmp r0, #0
; ARM-ENABLE-NEXT: bne LBB9_3
; ARM-ENABLE-NEXT: @ %bb.1: @ %if.then
; ARM-ENABLE-NEXT: sub r1, sp, #16
; ARM-ENABLE-NEXT: mov sp, r1
; ARM-ENABLE-NEXT: LBB9_2: @ %for.body
; ARM-ENABLE-NEXT: @ =>This Inner Loop Header: Depth=1
; ARM-ENABLE-NEXT: @ InlineAsm Start
; ARM-ENABLE-NEXT: mov r2, #1
; ARM-ENABLE-NEXT: @ InlineAsm End
; ARM-ENABLE-NEXT: add r0, r2, r0
; ARM-ENABLE-NEXT: str r0, [r1]
; ARM-ENABLE-NEXT: b LBB9_2
; ARM-ENABLE-NEXT: LBB9_3: @ %if.end
; ARM-ENABLE-NEXT: sub sp, r7, #8
; ARM-ENABLE-NEXT: pop {r4, r5, r7, pc}
;
; ARM-DISABLE-LABEL: infiniteloop:
; ARM-DISABLE: @ %bb.0: @ %entry
; ARM-DISABLE-NEXT: push {r4, r5, r7, lr}
; ARM-DISABLE-NEXT: add r7, sp, #8
; ARM-DISABLE-NEXT: mov r0, #0
; ARM-DISABLE-NEXT: cmp r0, #0
; ARM-DISABLE-NEXT: bne LBB9_3
; ARM-DISABLE-NEXT: @ %bb.1: @ %if.then
; ARM-DISABLE-NEXT: sub r1, sp, #16
; ARM-DISABLE-NEXT: mov sp, r1
; ARM-DISABLE-NEXT: LBB9_2: @ %for.body
; ARM-DISABLE-NEXT: @ =>This Inner Loop Header: Depth=1
; ARM-DISABLE-NEXT: @ InlineAsm Start
; ARM-DISABLE-NEXT: mov r2, #1
; ARM-DISABLE-NEXT: @ InlineAsm End
; ARM-DISABLE-NEXT: add r0, r2, r0
; ARM-DISABLE-NEXT: str r0, [r1]
; ARM-DISABLE-NEXT: b LBB9_2
; ARM-DISABLE-NEXT: LBB9_3: @ %if.end
; ARM-DISABLE-NEXT: sub sp, r7, #8
; ARM-DISABLE-NEXT: pop {r4, r5, r7, pc}
;
; THUMB-ENABLE-LABEL: infiniteloop:
; THUMB-ENABLE: @ %bb.0: @ %entry
; THUMB-ENABLE-NEXT: push {r4, r5, r7, lr}
; THUMB-ENABLE-NEXT: add r7, sp, #8
; THUMB-ENABLE-NEXT: movs r0, #0
; THUMB-ENABLE-NEXT: cbnz r0, LBB9_3
; THUMB-ENABLE-NEXT: @ %bb.1: @ %if.then
; THUMB-ENABLE-NEXT: sub.w r0, sp, #16
; THUMB-ENABLE-NEXT: mov sp, r0
; THUMB-ENABLE-NEXT: movs r1, #0
; THUMB-ENABLE-NEXT: LBB9_2: @ %for.body
; THUMB-ENABLE-NEXT: @ =>This Inner Loop Header: Depth=1
; THUMB-ENABLE-NEXT: @ InlineAsm Start
; THUMB-ENABLE-NEXT: mov.w r2, #1
; THUMB-ENABLE-NEXT: @ InlineAsm End
; THUMB-ENABLE-NEXT: add r1, r2
; THUMB-ENABLE-NEXT: str r1, [r0]
; THUMB-ENABLE-NEXT: b LBB9_2
; THUMB-ENABLE-NEXT: LBB9_3: @ %if.end
; THUMB-ENABLE-NEXT: sub.w r4, r7, #8
; THUMB-ENABLE-NEXT: mov sp, r4
; THUMB-ENABLE-NEXT: pop {r4, r5, r7, pc}
;
; THUMB-DISABLE-LABEL: infiniteloop:
; THUMB-DISABLE: @ %bb.0: @ %entry
; THUMB-DISABLE-NEXT: push {r4, r5, r7, lr}
; THUMB-DISABLE-NEXT: add r7, sp, #8
; THUMB-DISABLE-NEXT: movs r0, #0
; THUMB-DISABLE-NEXT: cbnz r0, LBB9_3
; THUMB-DISABLE-NEXT: @ %bb.1: @ %if.then
; THUMB-DISABLE-NEXT: sub.w r0, sp, #16
; THUMB-DISABLE-NEXT: mov sp, r0
; THUMB-DISABLE-NEXT: movs r1, #0
; THUMB-DISABLE-NEXT: LBB9_2: @ %for.body
; THUMB-DISABLE-NEXT: @ =>This Inner Loop Header: Depth=1
; THUMB-DISABLE-NEXT: @ InlineAsm Start
; THUMB-DISABLE-NEXT: mov.w r2, #1
; THUMB-DISABLE-NEXT: @ InlineAsm End
; THUMB-DISABLE-NEXT: add r1, r2
; THUMB-DISABLE-NEXT: str r1, [r0]
; THUMB-DISABLE-NEXT: b LBB9_2
; THUMB-DISABLE-NEXT: LBB9_3: @ %if.end
; THUMB-DISABLE-NEXT: sub.w r4, r7, #8
; THUMB-DISABLE-NEXT: mov sp, r4
; THUMB-DISABLE-NEXT: pop {r4, r5, r7, pc}
Fix possible infinite loop in shrink wrapping when searching for save/restore points. There is an infinite loop that can occur in Shrink Wrapping while searching for the Save/Restore points. Part of this search checks whether the save/restore points are located in different loop nests and if so, uses the (post) dominator trees to find the immediate (post) dominator blocks. However, if the current block does not have any immediate (post) dominators then this search will result in an infinite loop. This can occur in code containing an infinite loop. The modification checks whether the immediate (post) dominator is different from the current save/restore block. If it is not, then the search terminates and the current location is not considered as a valid save/restore point for shrink wrapping. Phabricator: http://reviews.llvm.org/D11607 llvm-svn: 244247
2015-08-07 03:01:57 +08:00
entry:
br i1 undef, label %if.then, label %if.end
if.then:
%ptr = alloca i32, i32 4
br label %for.body
for.body: ; preds = %for.body, %entry
%sum.03 = phi i32 [ 0, %if.then ], [ %add, %for.body ]
%call = tail call i32 asm sideeffect "mov $0, #1", "=r,~{r4}"()
%add = add nsw i32 %call, %sum.03
store i32 %add, i32* %ptr
br label %for.body
if.end:
ret void
}
[ShrinkWrap] Refactor the handling of infinite loop in the analysis. - Strenghten the logic to be sure we hoist the restore point out of the current loop. (The fixes a bug with infinite loop, added as part of the patch.) - Walk over the exit blocks of the current loop to conver to the desired restore point in one iteration of the update loop. llvm-svn: 247958
2015-09-18 07:21:34 +08:00
; Another infinite loop test this time with a body bigger than just one block.
[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; infiniteloop2
; pop
[ARM] Generate consistent frame records for Thumb2 There is not an official documented ABI for frame pointers in Thumb2, but we should try to emit something which is useful. We use r7 as the frame pointer for Thumb code, which currently means that if a function needs to save a high register (r8-r11), it will get pushed to the stack between the frame pointer (r7) and link register (r14). This means that while a stack unwinder can follow the chain of frame pointers up the stack, it cannot know the offset to lr, so does not know which functions correspond to the stack frames. To fix this, we need to push the callee-saved registers in two batches, with the first push saving the low registers, fp and lr, and the second push saving the high registers. This is already implemented, but previously only used for iOS. This patch turns it on for all Thumb2 targets when frame pointers are required by the ABI, and the frame pointer is r7 (Windows uses r11, so this isn't a problem there). If frame pointer elimination is enabled we still emit a single push/pop even if we need a frame pointer for other reasons, to avoid increasing code size. We must also ensure that lr is pushed to the stack when using a frame pointer, so that we end up with a complete frame record. Situations that could cause this were rare, because we already push lr in most situations so that we can return using the pop instruction. Differential Revision: https://reviews.llvm.org/D23516 llvm-svn: 279506
2016-08-23 17:19:22 +08:00
define void @infiniteloop2() "no-frame-pointer-elim"="true" {
[ShrinkWrap] Refactor the handling of infinite loop in the analysis. - Strenghten the logic to be sure we hoist the restore point out of the current loop. (The fixes a bug with infinite loop, added as part of the patch.) - Walk over the exit blocks of the current loop to conver to the desired restore point in one iteration of the update loop. llvm-svn: 247958
2015-09-18 07:21:34 +08:00
entry:
br i1 undef, label %if.then, label %if.end
if.then:
%ptr = alloca i32, i32 4
br label %for.body
for.body: ; preds = %for.body, %entry
%sum.03 = phi i32 [ 0, %if.then ], [ %add, %body1 ], [ 1, %body2]
%call = tail call i32 asm "mov $0, #0", "=r,~{r4}"()
%add = add nsw i32 %call, %sum.03
store i32 %add, i32* %ptr
br i1 undef, label %body1, label %body2
body1:
tail call void asm sideeffect "nop", "~{r4}"()
br label %for.body
body2:
tail call void asm sideeffect "nop", "~{r4}"()
br label %for.body
if.end:
ret void
}
; Another infinite loop test this time with two nested infinite loop.
[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; infiniteloop3
; bx lr
[ARM] Generate consistent frame records for Thumb2 There is not an official documented ABI for frame pointers in Thumb2, but we should try to emit something which is useful. We use r7 as the frame pointer for Thumb code, which currently means that if a function needs to save a high register (r8-r11), it will get pushed to the stack between the frame pointer (r7) and link register (r14). This means that while a stack unwinder can follow the chain of frame pointers up the stack, it cannot know the offset to lr, so does not know which functions correspond to the stack frames. To fix this, we need to push the callee-saved registers in two batches, with the first push saving the low registers, fp and lr, and the second push saving the high registers. This is already implemented, but previously only used for iOS. This patch turns it on for all Thumb2 targets when frame pointers are required by the ABI, and the frame pointer is r7 (Windows uses r11, so this isn't a problem there). If frame pointer elimination is enabled we still emit a single push/pop even if we need a frame pointer for other reasons, to avoid increasing code size. We must also ensure that lr is pushed to the stack when using a frame pointer, so that we end up with a complete frame record. Situations that could cause this were rare, because we already push lr in most situations so that we can return using the pop instruction. Differential Revision: https://reviews.llvm.org/D23516 llvm-svn: 279506
2016-08-23 17:19:22 +08:00
define void @infiniteloop3() "no-frame-pointer-elim"="true" {
[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; ARM-LABEL: infiniteloop3:
; ARM: @ %bb.0: @ %entry
; ARM-NEXT: mov r0, #0
; ARM-NEXT: cmp r0, #0
; ARM-NEXT: bne LBB11_5
; ARM-NEXT: @ %bb.1: @ %loop2a.preheader
; ARM-NEXT: mov r1, #0
; ARM-NEXT: mov r2, r0
; ARM-NEXT: b LBB11_3
; ARM-NEXT: LBB11_2: @ %loop2b
; ARM-NEXT: @ in Loop: Header=BB11_3 Depth=1
; ARM-NEXT: str r1, [r2]
; ARM-NEXT: mov r2, r1
; ARM-NEXT: mov r1, r3
; ARM-NEXT: LBB11_3: @ %loop1
; ARM-NEXT: @ =>This Inner Loop Header: Depth=1
; ARM-NEXT: ldr r3, [r0]
; ARM-NEXT: cmp r0, #0
; ARM-NEXT: bne LBB11_2
; ARM-NEXT: @ %bb.4: @ in Loop: Header=BB11_3 Depth=1
; ARM-NEXT: mov r0, r1
; ARM-NEXT: mov r1, r3
; ARM-NEXT: mov r2, r0
; ARM-NEXT: b LBB11_3
; ARM-NEXT: LBB11_5: @ %end
; ARM-NEXT: bx lr
;
; THUMB-LABEL: infiniteloop3:
; THUMB: @ %bb.0: @ %entry
; THUMB-NEXT: movs r0, #0
; THUMB-NEXT: cbnz r0, LBB11_5
; THUMB-NEXT: @ %bb.1: @ %loop2a.preheader
; THUMB-NEXT: movs r0, #0
; THUMB-NEXT: movs r1, #0
; THUMB-NEXT: mov r2, r0
; THUMB-NEXT: b LBB11_3
; THUMB-NEXT: LBB11_2: @ %loop2b
; THUMB-NEXT: @ in Loop: Header=BB11_3 Depth=1
; THUMB-NEXT: str r1, [r2]
; THUMB-NEXT: mov r2, r1
; THUMB-NEXT: mov r1, r3
; THUMB-NEXT: LBB11_3: @ %loop1
; THUMB-NEXT: @ =>This Inner Loop Header: Depth=1
; THUMB-NEXT: ldr r3, [r0]
; THUMB-NEXT: cmp r0, #0
; THUMB-NEXT: bne LBB11_2
; THUMB-NEXT: @ %bb.4: @ in Loop: Header=BB11_3 Depth=1
; THUMB-NEXT: mov r0, r1
; THUMB-NEXT: mov r1, r3
; THUMB-NEXT: mov r2, r0
; THUMB-NEXT: b LBB11_3
; THUMB-NEXT: LBB11_5: @ %end
; THUMB-NEXT: bx lr
; ARM-ENABLE-LABEL: infiniteloop3:
; ARM-ENABLE: @ %bb.0: @ %entry
; ARM-ENABLE-NEXT: mov r0, #0
; ARM-ENABLE-NEXT: cmp r0, #0
; ARM-ENABLE-NEXT: bne LBB11_5
; ARM-ENABLE-NEXT: @ %bb.1: @ %loop2a.preheader
; ARM-ENABLE-NEXT: mov r1, #0
; ARM-ENABLE-NEXT: mov r2, r0
; ARM-ENABLE-NEXT: b LBB11_3
; ARM-ENABLE-NEXT: LBB11_2: @ %loop2b
; ARM-ENABLE-NEXT: @ in Loop: Header=BB11_3 Depth=1
; ARM-ENABLE-NEXT: str r1, [r2]
; ARM-ENABLE-NEXT: mov r2, r1
; ARM-ENABLE-NEXT: mov r1, r3
; ARM-ENABLE-NEXT: LBB11_3: @ %loop1
; ARM-ENABLE-NEXT: @ =>This Inner Loop Header: Depth=1
; ARM-ENABLE-NEXT: ldr r3, [r0]
; ARM-ENABLE-NEXT: cmp r0, #0
; ARM-ENABLE-NEXT: bne LBB11_2
; ARM-ENABLE-NEXT: @ %bb.4: @ in Loop: Header=BB11_3 Depth=1
; ARM-ENABLE-NEXT: mov r0, r1
; ARM-ENABLE-NEXT: mov r1, r3
; ARM-ENABLE-NEXT: mov r2, r0
; ARM-ENABLE-NEXT: b LBB11_3
; ARM-ENABLE-NEXT: LBB11_5: @ %end
; ARM-ENABLE-NEXT: bx lr
;
; ARM-DISABLE-LABEL: infiniteloop3:
; ARM-DISABLE: @ %bb.0: @ %entry
; ARM-DISABLE-NEXT: mov r0, #0
; ARM-DISABLE-NEXT: cmp r0, #0
; ARM-DISABLE-NEXT: bne LBB11_5
; ARM-DISABLE-NEXT: @ %bb.1: @ %loop2a.preheader
; ARM-DISABLE-NEXT: mov r1, #0
; ARM-DISABLE-NEXT: mov r2, r0
; ARM-DISABLE-NEXT: b LBB11_3
; ARM-DISABLE-NEXT: LBB11_2: @ %loop2b
; ARM-DISABLE-NEXT: @ in Loop: Header=BB11_3 Depth=1
; ARM-DISABLE-NEXT: str r1, [r2]
; ARM-DISABLE-NEXT: mov r2, r1
; ARM-DISABLE-NEXT: mov r1, r3
; ARM-DISABLE-NEXT: LBB11_3: @ %loop1
; ARM-DISABLE-NEXT: @ =>This Inner Loop Header: Depth=1
; ARM-DISABLE-NEXT: ldr r3, [r0]
; ARM-DISABLE-NEXT: cmp r0, #0
; ARM-DISABLE-NEXT: bne LBB11_2
; ARM-DISABLE-NEXT: @ %bb.4: @ in Loop: Header=BB11_3 Depth=1
; ARM-DISABLE-NEXT: mov r0, r1
; ARM-DISABLE-NEXT: mov r1, r3
; ARM-DISABLE-NEXT: mov r2, r0
; ARM-DISABLE-NEXT: b LBB11_3
; ARM-DISABLE-NEXT: LBB11_5: @ %end
; ARM-DISABLE-NEXT: bx lr
;
; THUMB-ENABLE-LABEL: infiniteloop3:
; THUMB-ENABLE: @ %bb.0: @ %entry
; THUMB-ENABLE-NEXT: movs r0, #0
; THUMB-ENABLE-NEXT: cbnz r0, LBB11_5
; THUMB-ENABLE-NEXT: @ %bb.1: @ %loop2a.preheader
; THUMB-ENABLE-NEXT: movs r0, #0
; THUMB-ENABLE-NEXT: movs r1, #0
; THUMB-ENABLE-NEXT: mov r2, r0
; THUMB-ENABLE-NEXT: b LBB11_3
; THUMB-ENABLE-NEXT: LBB11_2: @ %loop2b
; THUMB-ENABLE-NEXT: @ in Loop: Header=BB11_3 Depth=1
; THUMB-ENABLE-NEXT: str r1, [r2]
; THUMB-ENABLE-NEXT: mov r2, r1
; THUMB-ENABLE-NEXT: mov r1, r3
; THUMB-ENABLE-NEXT: LBB11_3: @ %loop1
; THUMB-ENABLE-NEXT: @ =>This Inner Loop Header: Depth=1
; THUMB-ENABLE-NEXT: ldr r3, [r0]
; THUMB-ENABLE-NEXT: cmp r0, #0
; THUMB-ENABLE-NEXT: bne LBB11_2
; THUMB-ENABLE-NEXT: @ %bb.4: @ in Loop: Header=BB11_3 Depth=1
; THUMB-ENABLE-NEXT: mov r0, r1
; THUMB-ENABLE-NEXT: mov r1, r3
; THUMB-ENABLE-NEXT: mov r2, r0
; THUMB-ENABLE-NEXT: b LBB11_3
; THUMB-ENABLE-NEXT: LBB11_5: @ %end
; THUMB-ENABLE-NEXT: bx lr
;
; THUMB-DISABLE-LABEL: infiniteloop3:
; THUMB-DISABLE: @ %bb.0: @ %entry
; THUMB-DISABLE-NEXT: movs r0, #0
; THUMB-DISABLE-NEXT: cbnz r0, LBB11_5
; THUMB-DISABLE-NEXT: @ %bb.1: @ %loop2a.preheader
; THUMB-DISABLE-NEXT: movs r0, #0
; THUMB-DISABLE-NEXT: movs r1, #0
; THUMB-DISABLE-NEXT: mov r2, r0
; THUMB-DISABLE-NEXT: b LBB11_3
; THUMB-DISABLE-NEXT: LBB11_2: @ %loop2b
; THUMB-DISABLE-NEXT: @ in Loop: Header=BB11_3 Depth=1
; THUMB-DISABLE-NEXT: str r1, [r2]
; THUMB-DISABLE-NEXT: mov r2, r1
; THUMB-DISABLE-NEXT: mov r1, r3
; THUMB-DISABLE-NEXT: LBB11_3: @ %loop1
; THUMB-DISABLE-NEXT: @ =>This Inner Loop Header: Depth=1
; THUMB-DISABLE-NEXT: ldr r3, [r0]
; THUMB-DISABLE-NEXT: cmp r0, #0
; THUMB-DISABLE-NEXT: bne LBB11_2
; THUMB-DISABLE-NEXT: @ %bb.4: @ in Loop: Header=BB11_3 Depth=1
; THUMB-DISABLE-NEXT: mov r0, r1
; THUMB-DISABLE-NEXT: mov r1, r3
; THUMB-DISABLE-NEXT: mov r2, r0
; THUMB-DISABLE-NEXT: b LBB11_3
; THUMB-DISABLE-NEXT: LBB11_5: @ %end
; THUMB-DISABLE-NEXT: bx lr
[ShrinkWrap] Refactor the handling of infinite loop in the analysis. - Strenghten the logic to be sure we hoist the restore point out of the current loop. (The fixes a bug with infinite loop, added as part of the patch.) - Walk over the exit blocks of the current loop to conver to the desired restore point in one iteration of the update loop. llvm-svn: 247958
2015-09-18 07:21:34 +08:00
entry:
br i1 undef, label %loop2a, label %body
body: ; preds = %entry
br i1 undef, label %loop2a, label %end
loop1: ; preds = %loop2a, %loop2b
%var.phi = phi i32* [ %next.phi, %loop2b ], [ %var, %loop2a ]
%next.phi = phi i32* [ %next.load, %loop2b ], [ %next.var, %loop2a ]
%0 = icmp eq i32* %var, null
%next.load = load i32*, i32** undef
br i1 %0, label %loop2a, label %loop2b
loop2a: ; preds = %loop1, %body, %entry
%var = phi i32* [ null, %body ], [ null, %entry ], [ %next.phi, %loop1 ]
%next.var = phi i32* [ undef, %body ], [ null, %entry ], [ %next.load, %loop1 ]
br label %loop1
loop2b: ; preds = %loop1
%gep1 = bitcast i32* %var.phi to i32*
%next.ptr = bitcast i32* %gep1 to i32**
store i32* %next.phi, i32** %next.ptr
br label %loop1
end:
ret void
}
[ARM] Make sure we do not dereference the end iterator when accessing debug information. Although the problem was always here, it would only be exposed when shrink-wrapping is enable. rdar://problem/23110493 llvm-svn: 250352
2015-10-15 08:41:26 +08:00
; Function Attrs: nounwind readnone
declare double @llvm.pow.f64(double, double)
; This function needs to spill floating point registers to
NFC. Fix popular typo in comment 'deferencing' --> 'dereferencing'. Bonus changes, * placement in X86ISelLowering and 'exerce' -> 'exercise' in test. llvm-svn: 273984
2016-06-28 09:45:05 +08:00
; exercise the path where we were dereferencing the end iterator
[ARM] Make sure we do not dereference the end iterator when accessing debug information. Although the problem was always here, it would only be exposed when shrink-wrapping is enable. rdar://problem/23110493 llvm-svn: 250352
2015-10-15 08:41:26 +08:00
; to access debug info location while inserting the spill code
; during PEI with shrink-wrapping enable.
[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; debug_info:
[ARM] Make sure we do not dereference the end iterator when accessing debug information. Although the problem was always here, it would only be exposed when shrink-wrapping is enable. rdar://problem/23110493 llvm-svn: 250352
2015-10-15 08:41:26 +08:00
;
[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; {{tst r2, #1|lsls r1, r2, #31}}
; beq [[BB13:LBB[0-9_]+]]
[ARM] Make sure we do not dereference the end iterator when accessing debug information. Although the problem was always here, it would only be exposed when shrink-wrapping is enable. rdar://problem/23110493 llvm-svn: 250352
2015-10-15 08:41:26 +08:00
;
[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; push
[ARM] Make sure we do not dereference the end iterator when accessing debug information. Although the problem was always here, it would only be exposed when shrink-wrapping is enable. rdar://problem/23110493 llvm-svn: 250352
2015-10-15 08:41:26 +08:00
;
[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; {{tst r2, #1|lsls r1, r2, #31}}
; beq [[BB13:LBB[0-9_]+]]
[ARM] Make sure we do not dereference the end iterator when accessing debug information. Although the problem was always here, it would only be exposed when shrink-wrapping is enable. rdar://problem/23110493 llvm-svn: 250352
2015-10-15 08:41:26 +08:00
;
[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; bl{{x?}} _pow
[ARM] Make sure we do not dereference the end iterator when accessing debug information. Although the problem was always here, it would only be exposed when shrink-wrapping is enable. rdar://problem/23110493 llvm-svn: 250352
2015-10-15 08:41:26 +08:00
;
;
[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; pop
[ARM] Make sure we do not dereference the end iterator when accessing debug information. Although the problem was always here, it would only be exposed when shrink-wrapping is enable. rdar://problem/23110493 llvm-svn: 250352
2015-10-15 08:41:26 +08:00
;
[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; [[BB13]]:
; vldr
[ARM] Make sure we do not dereference the end iterator when accessing debug information. Although the problem was always here, it would only be exposed when shrink-wrapping is enable. rdar://problem/23110493 llvm-svn: 250352
2015-10-15 08:41:26 +08:00
;
[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; pop
[ARM] Make sure we do not dereference the end iterator when accessing debug information. Although the problem was always here, it would only be exposed when shrink-wrapping is enable. rdar://problem/23110493 llvm-svn: 250352
2015-10-15 08:41:26 +08:00
;
Fix test broken by r304020 It's a workaround because the test was flakey passing to begin with, but it looks like (going off commit history) it really did want to test in the presence of debug info, so keep that behavior (by adding something to the CU so it's not dropped) & restore the flakey pass in the process. (added a FIXME in case someone else decides to look at it later) llvm-svn: 304042
2017-05-27 06:11:18 +08:00
; FIXME: This is flakey passing by finding 'bl' somewhere amongst the debug
; info (like labels named 'line_table) not because it's found a bl instruction.
;
[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; bl
[ARM] Generate consistent frame records for Thumb2 There is not an official documented ABI for frame pointers in Thumb2, but we should try to emit something which is useful. We use r7 as the frame pointer for Thumb code, which currently means that if a function needs to save a high register (r8-r11), it will get pushed to the stack between the frame pointer (r7) and link register (r14). This means that while a stack unwinder can follow the chain of frame pointers up the stack, it cannot know the offset to lr, so does not know which functions correspond to the stack frames. To fix this, we need to push the callee-saved registers in two batches, with the first push saving the low registers, fp and lr, and the second push saving the high registers. This is already implemented, but previously only used for iOS. This patch turns it on for all Thumb2 targets when frame pointers are required by the ABI, and the frame pointer is r7 (Windows uses r11, so this isn't a problem there). If frame pointer elimination is enabled we still emit a single push/pop even if we need a frame pointer for other reasons, to avoid increasing code size. We must also ensure that lr is pushed to the stack when using a frame pointer, so that we end up with a complete frame record. Situations that could cause this were rare, because we already push lr in most situations so that we can return using the pop instruction. Differential Revision: https://reviews.llvm.org/D23516 llvm-svn: 279506
2016-08-23 17:19:22 +08:00
define float @debug_info(float %gamma, float %slopeLimit, i1 %or.cond, double %tmp) "no-frame-pointer-elim"="true" {
[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; ARM-LABEL: debug_info:
; ARM: @ %bb.0: @ %bb
; ARM-NEXT: push {r4, r7, lr}
; ARM-NEXT: add r7, sp, #4
; ARM-NEXT: sub r4, sp, #16
; ARM-NEXT: bfc r4, #0, #4
; ARM-NEXT: mov sp, r4
; ARM-NEXT: tst r2, #1
; ARM-NEXT: vst1.64 {d8, d9}, [r4:128]
; ARM-NEXT: beq LBB12_2
; ARM-NEXT: @ %bb.1: @ %bb3
; ARM-NEXT: ldr r1, [r7, #8]
; ARM-NEXT: vmov s16, r0
; ARM-NEXT: mov r0, r3
; ARM-NEXT: mov r2, r3
; ARM-NEXT: vmov d9, r3, r1
; ARM-NEXT: mov r3, r1
; ARM-NEXT: bl _pow
; ARM-NEXT: vmov.f32 s0, #1.000000e+00
; ARM-NEXT: vmov.f64 d16, #1.000000e+00
; ARM-NEXT: vadd.f64 d16, d9, d16
[ARM] Generate vcmp instead of vcmpe Based on the discussion in http://lists.llvm.org/pipermail/llvm-dev/2019-October/135574.html, the conclusion was reached that the ARM backend should produce vcmp instead of vcmpe instructions by default, i.e. not be producing an Invalid Operation exception when either arguments in a floating point compare are quiet NaNs. In the future, after constrained floating point intrinsics for floating point compare have been introduced, vcmpe instructions probably should be produced for those intrinsics - depending on the exact semantics they'll be defined to have. This patch logically consists of the following parts: - Revert http://llvm.org/viewvc/llvm-project?rev=294945&view=rev and http://llvm.org/viewvc/llvm-project?rev=294968&view=rev, which implemented fine-tuning for when to produce vcmpe (i.e. not do it for equality comparisons). The complexity introduced by those patches isn't needed anymore if we just always produce vcmp instead. Maybe these patches need to be reintroduced again once support is needed to map potential LLVM-IR constrained floating point compare intrinsics to the ARM instruction set. - Simply select vcmp, instead of vcmpe, see simple changes in lib/Target/ARM/ARMInstrVFP.td - Adapt lots of tests that tested for vcmpe (instead of vcmp). For all of these test, the intent of what is tested for isn't related to whether the vcmp should produce an Invalid Operation exception or not. Fixes PR43374. Differential Revision: https://reviews.llvm.org/D68463 llvm-svn: 374025
2019-10-08 16:25:42 +08:00
; ARM-NEXT: vcmp.f32 s16, s0
[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; ARM-NEXT: vmrs APSR_nzcv, fpscr
; ARM-NEXT: vmov d17, r0, r1
; ARM-NEXT: vmov.f64 d18, d9
; ARM-NEXT: vadd.f64 d17, d17, d17
; ARM-NEXT: vmovgt.f64 d18, d16
; ARM-NEXT: vcmp.f64 d18, d9
; ARM-NEXT: vmrs APSR_nzcv, fpscr
; ARM-NEXT: vmovne.f64 d9, d17
; ARM-NEXT: vcvt.f32.f64 s0, d9
; ARM-NEXT: b LBB12_3
; ARM-NEXT: LBB12_2:
; ARM-NEXT: vldr s0, LCPI12_0
; ARM-NEXT: LBB12_3: @ %bb13
; ARM-NEXT: mov r4, sp
; ARM-NEXT: vld1.64 {d8, d9}, [r4:128]
; ARM-NEXT: vmov r0, s0
; ARM-NEXT: sub sp, r7, #4
; ARM-NEXT: pop {r4, r7, pc}
; ARM-NEXT: .p2align 2
; ARM-NEXT: @ %bb.4:
; ARM-NEXT: .data_region
; ARM-NEXT: LCPI12_0:
; ARM-NEXT: .long 0 @ float 0
; ARM-NEXT: .end_data_region
;
; THUMB-LABEL: debug_info:
; THUMB: @ %bb.0: @ %bb
; THUMB-NEXT: push {r4, r7, lr}
; THUMB-NEXT: add r7, sp, #4
; THUMB-NEXT: sub.w r4, sp, #16
; THUMB-NEXT: bfc r4, #0, #4
; THUMB-NEXT: mov sp, r4
; THUMB-NEXT: lsls r1, r2, #31
; THUMB-NEXT: vst1.64 {d8, d9}, [r4:128]
; THUMB-NEXT: beq LBB12_2
; THUMB-NEXT: @ %bb.1: @ %bb3
; THUMB-NEXT: ldr r1, [r7, #8]
; THUMB-NEXT: vmov s16, r0
; THUMB-NEXT: mov r0, r3
; THUMB-NEXT: mov r2, r3
; THUMB-NEXT: vmov d9, r3, r1
; THUMB-NEXT: mov r3, r1
; THUMB-NEXT: bl _pow
; THUMB-NEXT: vmov.f32 s0, #1.000000e+00
; THUMB-NEXT: vmov.f64 d16, #1.000000e+00
; THUMB-NEXT: vmov.f64 d18, d9
[ARM] Generate vcmp instead of vcmpe Based on the discussion in http://lists.llvm.org/pipermail/llvm-dev/2019-October/135574.html, the conclusion was reached that the ARM backend should produce vcmp instead of vcmpe instructions by default, i.e. not be producing an Invalid Operation exception when either arguments in a floating point compare are quiet NaNs. In the future, after constrained floating point intrinsics for floating point compare have been introduced, vcmpe instructions probably should be produced for those intrinsics - depending on the exact semantics they'll be defined to have. This patch logically consists of the following parts: - Revert http://llvm.org/viewvc/llvm-project?rev=294945&view=rev and http://llvm.org/viewvc/llvm-project?rev=294968&view=rev, which implemented fine-tuning for when to produce vcmpe (i.e. not do it for equality comparisons). The complexity introduced by those patches isn't needed anymore if we just always produce vcmp instead. Maybe these patches need to be reintroduced again once support is needed to map potential LLVM-IR constrained floating point compare intrinsics to the ARM instruction set. - Simply select vcmp, instead of vcmpe, see simple changes in lib/Target/ARM/ARMInstrVFP.td - Adapt lots of tests that tested for vcmpe (instead of vcmp). For all of these test, the intent of what is tested for isn't related to whether the vcmp should produce an Invalid Operation exception or not. Fixes PR43374. Differential Revision: https://reviews.llvm.org/D68463 llvm-svn: 374025
2019-10-08 16:25:42 +08:00
; THUMB-NEXT: vcmp.f32 s16, s0
[FIX] Forces shrink wrapping to consider any memory access as aliasing with the stack Summary: Relate bug: https://bugs.llvm.org/show_bug.cgi?id=37472 The shrink wrapping pass prematurally restores the stack, at a point where the stack might still be accessed. Taking an exception can cause the stack to be corrupted. As a first approach, this patch is overly conservative, assuming that any instruction that may load or store could access the stack. Reviewers: dmgreen, qcolombet Reviewed By: qcolombet Subscribers: simpal01, efriedma, eli.friedman, javed.absar, llvm-commits, eugenis, chill, carwil, thegameg Tags: #llvm Differential Revision: https://reviews.llvm.org/D63152 llvm-svn: 363265
2019-06-13 21:56:19 +08:00
; THUMB-NEXT: vadd.f64 d16, d9, d16
; THUMB-NEXT: vmrs APSR_nzcv, fpscr
; THUMB-NEXT: it gt
; THUMB-NEXT: vmovgt.f64 d18, d16
; THUMB-NEXT: vcmp.f64 d18, d9
; THUMB-NEXT: vmov d17, r0, r1
; THUMB-NEXT: vmrs APSR_nzcv, fpscr
; THUMB-NEXT: vadd.f64 d17, d17, d17
; THUMB-NEXT: it ne
; THUMB-NEXT: vmovne.f64 d9, d17
; THUMB-NEXT: vcvt.f32.f64 s0, d9
; THUMB-NEXT: b LBB12_3
; THUMB-NEXT: LBB12_2:
; THUMB-NEXT: vldr s0, LCPI12_0
; THUMB-NEXT: LBB12_3: @ %bb13
; THUMB-NEXT: mov r4, sp
; THUMB-NEXT: vld1.64 {d8, d9}, [r4:128]
; THUMB-NEXT: subs r4, r7, #4
; THUMB-NEXT: vmov r0, s0
; THUMB-NEXT: mov sp, r4
; THUMB-NEXT: pop {r4, r7, pc}
; THUMB-NEXT: .p2align 2
; THUMB-NEXT: @ %bb.4:
; THUMB-NEXT: .data_region
; THUMB-NEXT: LCPI12_0:
; THUMB-NEXT: .long 0 @ float 0
; THUMB-NEXT: .end_data_region
[ARM] Make sure we do not dereference the end iterator when accessing debug information. Although the problem was always here, it would only be exposed when shrink-wrapping is enable. rdar://problem/23110493 llvm-svn: 250352
2015-10-15 08:41:26 +08:00
bb:
br i1 %or.cond, label %bb3, label %bb13
bb3: ; preds = %bb
%tmp4 = fcmp ogt float %gamma, 1.000000e+00
%tmp5 = fadd double 1.000000e+00, %tmp
%tmp6 = select i1 %tmp4, double %tmp5, double %tmp
%tmp10 = tail call double @llvm.pow.f64(double %tmp, double %tmp)
%tmp11 = fcmp une double %tmp6, %tmp
%tmp12 = fadd double %tmp10, %tmp10
%cutoff.0 = select i1 %tmp11, double %tmp12, double %tmp
%phitmp = fptrunc double %cutoff.0 to float
br label %bb13
bb13: ; preds = %bb3, %bb
%cutoff.1 = phi float [ 0.000000e+00, %bb ], [ %phitmp, %bb3 ]
ret float %cutoff.1
}
!llvm.dbg.cu = !{!0}
!llvm.module.flags = !{!3}
Fix test broken by r304020 It's a workaround because the test was flakey passing to begin with, but it looks like (going off commit history) it really did want to test in the presence of debug info, so keep that behavior (by adding something to the CU so it's not dropped) & restore the flakey pass in the process. (added a FIXME in case someone else decides to look at it later) llvm-svn: 304042
2017-05-27 06:11:18 +08:00
!0 = distinct !DICompileUnit(language: DW_LANG_C_plus_plus, file: !1, producer: "LLVM", isOptimized: true, runtimeVersion: 0, emissionKind: FullDebug, enums: !2, retainedTypes: !4, globals: !2, imports: !2)
[ARM] Make sure we do not dereference the end iterator when accessing debug information. Although the problem was always here, it would only be exposed when shrink-wrapping is enable. rdar://problem/23110493 llvm-svn: 250352
2015-10-15 08:41:26 +08:00
!1 = !DIFile(filename: "a.cpp", directory: "b")
!2 = !{}
!3 = !{i32 2, !"Debug Info Version", i32 3}
Fix test broken by r304020 It's a workaround because the test was flakey passing to begin with, but it looks like (going off commit history) it really did want to test in the presence of debug info, so keep that behavior (by adding something to the CU so it's not dropped) & restore the flakey pass in the process. (added a FIXME in case someone else decides to look at it later) llvm-svn: 304042
2017-05-27 06:11:18 +08:00
!4 = !{!5}
!5 = !DIBasicType(name: "int", size: 32, encoding: DW_ATE_signed)