[all-commits] [llvm/llvm-project] c65ef8: RegAllocGreedy: Fix use after free during last cha...

[Matt Arsenault via All-commits]

  Branch: refs/heads/users/arsenm/greedy-only-unassign-after-last-chance-recoloring-if-assigned
  Home:   https://github.com/llvm/llvm-project
  Commit: c65ef863a9411e740995a1f9923697db4f0afbde
      https://github.com/llvm/llvm-project/commit/c65ef863a9411e740995a1f9923697db4f0afbde
  Author: Matt Arsenault <Matthew.Arsenault at amd.com>
  Date:   2025-01-03 (Fri, 03 Jan 2025)

  Changed paths:
    M llvm/lib/CodeGen/RegAllocGreedy.cpp
    A llvm/test/CodeGen/AMDGPU/inflated-reg-class-snippet-copy-use-after-free.mir
    A llvm/test/CodeGen/AMDGPU/swdev502267-use-after-free-last-chance-recoloring-alloc-succeeds.mir

  Log Message:
  -----------
  RegAllocGreedy: Fix use after free during last chance recoloring

Last chance recoloring can delete the current fixed interval
during recursive assignment of interfering live intervals. Check
if the virtual register value was assigned before attempting the
unassignment, as is done in other scenarios. This relies on the fact
that we do not recycle virtual register numbers.

I have only seen this occur in error situations where the allocation
will fail, but I think this can theoretically happen in working
allocations.

This feels very brute force, but I've spent over a week debugging
this and this is what works without any lit regressions. The surprising
piece to me was that unspillable live ranges may be spilled, and
a number of tests rely on optimizations occurring on them. My other
attempts to fixed this mostly revolved around not identifying unspillable
live ranges as snippet copies. I've also discovered we're making some
unproductive live range splits with subranges. If we avoid such splits,
some of the unspillable copies disappear but mandating that be precise
to fix a use after free doesn't sound right.



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications