[llvm-bugs] [Bug 39671] New: Bad interaction between hot/cold splitting and stack coloring

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=39671

            Bug ID: 39671
           Summary: Bad interaction between hot/cold splitting and stack
                    coloring
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Interprocedural Optimizations
          Assignee: unassignedbugs at nondot.org
          Reporter: vsk at apple.com
                CC: llvm-bugs at lists.llvm.org

Created attachment 21121
  --> https://bugs.llvm.org/attachment.cgi?id=21121&action=edit
Reproduces the stack coloring issue when passed to llc -O3.

With hot/cold splitting enabled, clang miscompiles itself in a stage2
ThinLTO+PGO build. I see this crash when running
test/Transforms/LowerExpectIntrinsic/phi_merge.ll through the stage2 opt
binary:

```
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS
(code=EXC_I386_GPFLT)
  * frame #0: 0x00000001013afaf9
opt`handlePhiDef(llvm::CallInst*)::$_0::operator()(llvm::APInt const&) const +
73
    frame #1: 0x00000001013afff8 opt`lowerExpectIntrinsic(llvm::Function&)
(.cold.13) + 104
    frame #2: 0x00000001013af762 opt`lowerExpectIntrinsic(llvm::Function&) +
1570
```

The problem is that StackColoring merges stack slots which are in-use at the
same time in the outlined function.

Here is the call to the outlined function
("lowerExpectIntrinsic(llvm::Function&) (.cold.13)"):

```
codeRepl209:                                      ; preds =
%_ZN4llvm3isaINS_7PHINodeEPNS_5ValueEEEbRKT0_.exit.i
  call void
@_ZL20lowerExpectIntrinsicRN4llvm8FunctionE.cold.13(%"class.llvm::SmallVector.141"*
%Operations.i, %"class.llvm::Value"* %.in299.i, %"class.llvm::APInt"*
%ref.tmp43.i, %"class.llvm::Value"* %231, %"class.llvm::Value"* %Val.i.i255, [2
x i32]* %ref.tmp2.i, %"class.llvm::APInt"* %237) #14
  br label %cleanup75.i
```

>From -debug-only=stack-coloring output, you can see that the slots for
"ref.tmp2.i" and "Operations.i" are merged together (look for the edges "#5 ->
#2"; "#5 -> #1"), despite the fact that these are both passed in to the
outlined function, and are possibly-used at the same time.

```
********** Function: _ZL20lowerExpectIntrinsicRN4llvm8FunctionE
Found a lifetime start marker for slot #2 with allocation: Operations.i
Found a lifetime start marker for slot #4 with allocation: MDB.i
Found a lifetime start marker for slot #1 with allocation: ref.tmp2.i
Found a lifetime start marker for slot #7 with allocation: MDB.i.i
Found a lifetime start marker for slot #5 with allocation: Weights.i
Found a lifetime start marker for slot #6 with allocation: ref.tmp34.i
...
Merging #5 and slots #2 together. 
Merging #5 and slots #1 together. 
Merging #4 and slots #6 together. 
Merging #4 and slots #7 together.
Merge 4 slots. Saved 72 bytes
```

I verified that disabling stack coloring hides the crash. In fact, with stack
coloring disabled and splitting enabled, the full stage2 run check-{llvm,clang}
succeeds without regressions.

Attachments:
- 661.4.opt.nodbg.ll: Reproduces the stack coloring issue when passed to llc
-O3.
- non-trashy.661.4.opt.nodbg.ll: The same as 661.4.opt.nodbg.ll, but
lifetime.{start, end} markers are stripped out of the caller function
(lowerExpectIntrinsic). This does not crash.

Note: I am testing with https://reviews.llvm.org/D53887,
https://reviews.llvm.org/D54189, and https://reviews.llvm.org/D54244 applied to
ToT.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20181114/39310494/attachment-0001.html>