[llvm] [AMDGPU] When allocating VGPRs, VGPR spills are not part of the prologue (PR #109439)

[via llvm-commits]

alex-t wrote:

> > My point is the wwm_vgpr_reload is part of the block prologue, right?
> 
> Yes. In such cases, the wwm-spill-restore should precede the `readlane` that restores the sgpr. This could frequently occur in the FastAlloc path. The liveout values are spilled at the block end and restored at the successor blocks' begin. Matt had a workaround to fix such cases in the fastalloc. https://github.com/llvm/llvm-project/blob/main/llvm/lib/CodeGen/RegAllocFast.cpp#L656 https://github.com/llvm/llvm-project/blob/main/llvm/lib/CodeGen/RegAllocFast.cpp#L699 But this could be an edge case in the Greedy allocator and cause problems. The InlineSpiller and SplitKit need a similar workaround made by Matt. They seem quite ugly though. I don't recollect exactly why I used `isSpill` in the original patch. This could be one of the reasons.
> 
> We could conditionally add the wwm-spill-restore to the block begin when there is already an instruction in the bb-prolog that uses this restored register. The `isBasicBlockPrologue` function can accommodate that.

The isSGPRSpill is still too large a hummer. SGPR spills have nothing to do with the prologue. We only need SGPR reloads that define registers used by other prologue instructions. I tried a more selective algorithm but it caused a segmentation fault in the blender.
I haven't yet found the exact reason. The spill/reload pattern seems to change significantly if we exclude unnecessary spills/reloads. 

> > The isSGPRSpill is still too large a hummer.
> 
> What do you think about committing this patch as a small step in the right direction? We can refine it more later.

I agree with that. I would have enough time to sort out what is wrong with the more selective approach provided this is committed and no more app crashes happen.

https://github.com/llvm/llvm-project/pull/109439