[llvm-bugs] [Bug 38232] New: Method with a swifterror param and ssp causing llc crash during livevars pass

[via llvm-bugs]

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

            Bug ID: 38232
           Summary: Method with a swifterror param and ssp causing llc
                    crash during livevars pass
           Product: libraries
           Version: trunk
          Hardware: All
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Common Code Generator Code
          Assignee: unassignedbugs at nondot.org
          Reporter: cperfetto at arxan.com
                CC: llvm-bugs at lists.llvm.org

Created attachment 20579
  --> https://bugs.llvm.org/attachment.cgi?id=20579&action=edit
minimal input bitcode to repro the llc crash

I get the following llc crash when attempting to lower the attached minrepro.ll
bitcode.

>$ ./llc -march=x86-64 minrepro.ll
Assertion failed: (MBB != &MF->front() && "Can't find reaching def for
virtreg"), function MarkVirtRegAliveInBlock, file
/_/git/llvm/lib/CodeGen/LiveVariables.cpp, line 113.
0  llc                      0x0000000105fa59ec
llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 60
1  llc                      0x0000000105fa5f69
PrintStackTraceSignalHandler(void*) + 25
2  llc                      0x0000000105fa299b llvm::sys::RunSignalHandlers() +
987
3  llc                      0x0000000105fa6b5a SignalHandler(int) + 490
4  libsystem_platform.dylib 0x00007fff6c13df5a _sigtramp + 26
5  libsystem_platform.dylib 0x00007ff52bd15a20 _sigtramp + 3216866016
6  libsystem_c.dylib        0x00007fff6bedb1ae abort + 127
7  libsystem_c.dylib        0x00007fff6bea31ac basename_r + 0
8  llc                      0x0000000104d4c08b
llvm::LiveVariables::MarkVirtRegAliveInBlock(llvm::LiveVariables::VarInfo&,
llvm::MachineBasicBlock*, llvm::MachineBasicBlock*,
std::__1::vector<llvm::MachineBasicBlock*,
std::__1::allocator<llvm::MachineBasicBlock*> >&) + 1739
9  llc                      0x0000000104d4dad3
llvm::LiveVariables::MarkVirtRegAliveInBlock(llvm::LiveVariables::VarInfo&,
llvm::MachineBasicBlock*, llvm::MachineBasicBlock*) + 675
10 llc                      0x0000000104d511a8
llvm::LiveVariables::runOnBlock(llvm::MachineBasicBlock*, unsigned int) + 1304
11 llc                      0x0000000104d519c4
llvm::LiveVariables::runOnMachineFunction(llvm::MachineFunction&) + 644
12 llc                      0x0000000104e19f91
llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 449
13 llc                      0x00000001053fe33f
llvm::FPPassManager::runOnFunction(llvm::Function&) + 399
14 llc                      0x00000001053fe845
llvm::FPPassManager::runOnModule(llvm::Module&) + 117
15 llc                      0x00000001053ff52f (anonymous
namespace)::MPPassManager::runOnModule(llvm::Module&) + 1967
16 llc                      0x00000001053feb06
llvm::legacy::PassManagerImpl::run(llvm::Module&) + 342
17 llc                      0x0000000105400181
llvm::legacy::PassManager::run(llvm::Module&) + 33
18 llc                      0x0000000102e3948d compileModule(char**,
llvm::LLVMContext&) + 18653
19 llc                      0x0000000102e33e75 main + 4165
20 libdyld.dylib            0x00007fff6be2f015 start + 1
Stack dump:
0.      Program arguments: ./llc -march=x86-64 minrepro.ll 
1.      Running pass 'Function Pass Manager' on module 'minrepro.ll'.
2.      Running pass 'Live Variable Analysis' on function '@func1'
Abort trap: 6



Repros for archs: arm64, x86-64
Does not repro for arch: x86
Does not repro if fast isel is enabled with -fast-isel
Does not rerpo if the swifterror function parameter attribute is removed (see
minrepro.ll attachment)
Does not repro if ssp function attribute is removed (see minrepro.ll
attachment)
Does not repro if optnone / noinline are removed (see minrepro.ll attachment)



Some initial investigation which may or may not be relevant:

In an MIR dump right before the "livevars" pass (./llc -march=x86-64
minrepro.ll -stop-before=livevars -o minrepro_pre_livevars.mir) I noticed that
a single PHI instruction in basic block "bb.4.BLK1" references vreg %5. I found
this odd because vreg %5 is defined in the basic block "bb.3.BLK1", a leaf node
that would not have been executed before reaching the PHI instruction.

Further investigation found that the PHI node (along with another copy
instruction) are generated in the propagateSwiftErrorVRegs() method in
SelectionDAGISel.cpp, and only occurs if the swifterror parameter is present.

My current theory is that the splitting of basic blocks in order to insert
stack protector during instruction selection is causing the data in
FunctionLoweringInfo::SwiftErrorVRegDefMap and
FunctionLoweringInfo::SwiftErrorVRegUpwardsUse to become invalid (since the
basic blocks here were added before being split), leading to the generation of
an invalid PHI or Copy instruction in propagateSwiftErrorVRegs().



While I think the above theory may be the problem, I am not familiar enough
with this area of LLVM to know what sort of solution would be best here. Any
feedback, corrections, or additional insights would be greatly appreciated.

-- 
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/20180719/5881b31f/attachment-0001.html>