[llvm] [ShrinkWrap][NFC] Test with load from constant pool preventing shrink (PR #162476)

[Sushant Gokhale via llvm-commits]

================
@@ -24,8 +21,11 @@
     br label %common.ret
   }
 ...
-# Following code has a load from constant pool. Accessing constant pool must not
-# be considered as a stack access and hence, shrink wrapping must happen.
+# FIXME: Following code has a load from constant pool. Accessing constant pool
+# must not be considered as a stack access and hence, shrink wrapping must
+# happen.
+# CHECK-NOT: savePoint
+# CHECK-NOT: restorePoint
----------------
sushgokh wrote:

Just to give some context on why I am doing this:
Right now, shrink wrapping is not happening due to this constant pool load. So, by default, **it considers entry/exit of the function as save/restore point and it does not emit any information on savePoint/restorePoint BB**. e.g. for the concerned test,
```
...
---
name:            shrink_wrap_load_from_const_pool
alignment:       1
tracksRegLiveness: true
noPhis:          true
isSSA:           true
noVRegs:         true
hasFakeUses:     false
frameInfo:
  maxAlignment:    1
  maxCallFrameSize: 0
constants:
  - id:              0
    value:           'double 3.125500e+02'
    alignment:       8
machineFunctionInfo: {}
body:             |
  bb.0.entry:

```
Hence, the CHECK-NOT. 

Now, once I have a patch to address this issue, we will have savePoint/restorePoint BBs emitted by the pass as  you say e.g.
```
; CHECK:      name:            compiler_pop_stack
 ; CHECK:      frameInfo:
 ; CHECK:        savePoint:
 ; CHECK-NEXT:     - point:           '%bb.1'
 ; CHECK:        restorePoint:
 ; CHECK-NEXT:     - point:           '%bb.7'
```

Is there still any correction needed? If yes, I am not able to understand what's needed. Maybe you can give example.

https://github.com/llvm/llvm-project/pull/162476