[PATCH] D26648: Clarify semantic of reserved registers.

[Quentin Colombet via llvm-commits]

ARM has a similar problem and we solved it with “fancy” allocation order:
commit 8927f6cd0f8d7614e8682a2da08f0a9769be9603
Author: Tim Northover <tnorthover at apple.com>
Date:   Mon Aug 3 17:20:10 2015 +0000

    ARM: prefer allocating VFP regs at stride 4 on Darwin.
    
    This is necessary for WatchOS support, where the compact unwind format assumes
    this kind of layout. For now we only want this on Swift-like CPUs though, where
    it's been the Xcode behaviour for ages. Also, since it can expand the prologue
    we don't want it at -Oz.
    
    git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@243884 91177308-0d34-0410-b5e6-96231b3b80d8

> On Nov 14, 2016, at 6:15 PM, Matthias Braun <matze at braunis.de> wrote:
> 
> MatzeB added a reviewer: sdardis.
> MatzeB added a comment.
> 
> These new rules break existing use in Mips :-(
> 
> Mips has 32bit floatregs F0-F31, each pair forms a double reg (F0+https://reviews.llvm.org/F1=D0, https://reviews.llvm.org/F2+https://reviews.llvm.org/F3=https://reviews.llvm.org/D1, ...). There is an option in the mips backend that aims at disabling the odd F registers, so 32bit float values only end up in F0, https://reviews.llvm.org/F2, https://reviews.llvm.org/F4, ... In this case it is actually expected that the register allocator still assigns the D0-D15 as usual even though the would indirectly use https://reviews.llvm.org/F1,https://reviews.llvm.org/F3,...
> 
> Is there another way to handle this in the mips target?
> 
> 
> Repository:
>  rL LLVM
> 
> https://reviews.llvm.org/D26648
> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20161114/da82c2ca/attachment.html>