[llvm-bugs] [Bug 46767] New: [MachineOutliner][AArch64] Improve the state of stack fixups.

[via llvm-bugs]

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

            Bug ID: 46767
           Summary: [MachineOutliner][AArch64] Improve the state of stack
                    fixups.
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Backend: AArch64
          Assignee: unassignedbugs at nondot.org
          Reporter: puyan at puyan.org
                CC: arnaud.degrandmaison at arm.com,
                    llvm-bugs at lists.llvm.org, smithp352 at googlemail.com,
                    Ties.Stuij at arm.com

Created attachment 23748
  --> https://bugs.llvm.org/attachment.cgi?id=23748&action=edit
To Repro: llc -o - ld-temp-named.ll

The MachineOutliner on AArch64 hits an assert for cases where there are stack
fixups required for the default FrameID type MachineOutlinerDefault.

This is set in llvm/lib/Target/AArch64/AArch64InstrInfo.cpp at
AArch64InstrInfo::getOutliningCandidateInfo() in cases where an outliner
candidates that has a noreturn caller, no LR, no spare general purpose
registers, and no use of SP. When the outliner here sets the candidate type to
MachineOutlinerDefault, it his highly likely that an assert is hit in the same
file at AArch64InstrInfo::buildOutlinedFrame():

```
    assert(OF.FrameConstructionID != MachineOutlinerDefault &&
           "Can only fix up stack references once")
```

In the the cases where the candidate has a call or a noreturn caller I have a
patch for the outliner to bail out: https://reviews.llvm.org/D83923



>From speaking with @paquette it sounds like the assert is there because we want
to know when these cases happen since this two pass stack fixup path is not
adequately tested and checked for any potential illegal code that may be
generated.

So I filed _this_ bug to track the progress of this scenario, and to reference
the bugzilla ID in comments associated with this issue. 

I originally hit the assert when building the llvm test suite for
aarch64-unknown-linux-gnu with -Oz and -flto=full. I have a reduced IR from the
test that caused the assert attached (MultiSource/Applications/Burg). Some of
my colleagues also hit it with -flto=thin when building some apps internally.

-- 
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/20200717/0643529e/attachment.html>