[all-commits] [llvm/llvm-project] 5398c2: 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: 5398c210bbd40b5b3b3f4524dfec7257c446529d
      https://github.com/llvm/llvm-project/commit/5398c210bbd40b5b3b3f4524dfec7257c446529d
  Author: Matt Arsenault <Matthew.Arsenault at amd.com>
  Date:   2024-12-20 (Fri, 20 Dec 2024)

  Changed paths:
    M llvm/lib/CodeGen/RegAllocGreedy.cpp
    A llvm/test/CodeGen/AMDGPU/inflated-reg-class-snippet-copy-use-after-free.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