[LLVMbugs] [Bug 7407] New: X86 codegen segfault using deleted node

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=7407

           Summary: X86 codegen segfault using deleted node
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: X86
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: greened at obbligato.org
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=5054)
 --> (http://llvm.org/bugs/attachment.cgi?id=5054)
bugpoint-reduced testcase that crashes llc for x86

The attached testcase triggers the situation that revision 98780 tries to
address.  Unfortunately, revision 98780 isn't a real solution to the problem
because even if we back out from selecting a particular addressing mode, the
DAG node has already been deleted.  References to that node exist in multiple
places within the instruction selector (on the stack, etc.).  Any subsequent
reference to the deleted node will cause problems.  This is exactly what
happens with this testcase.

I can think of at least three ways to address the problem:

1. Recode the AND case of MatchAddressRecursively to not use
ReplaceAllUsesWith, perhaps by updating the node in place as in MorphNodeTo. 
The catch here is if the newly formed node already exists in the CSE tables,
the original node won't be updated and we will generate the wrong result in the
address match logic.  So we would need something a bit more hacky than
MorphNodeTo.

2. Track all live uses of the node with some kind of DAGUpdateListener.  This
is what 98780 tries to do but it misses the nodes reference in the stack up the
call chain.

3. Disable the AND case of MatchAddressRecursively entirely.

Option 1 seems complicated due to the requirements of the CSE table.  I'm not
familiar enough with that area to know if this is a viable solution.  Option 2
is feasible but could get expensive and would require some recoding of
DAGIselEmitter and fiends to generate the appropriate tracking code (adding
nodes on the stack to the UpdateListener).  It has the potential to require
widespread API changes.  Option 3 is not very palatable at all.  Addressing
computation is one of the most performance-sensitive areas on the X86
architecture.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.