[llvm-commits] [llvm] r143177 - in /llvm/trunk: lib/CodeGen/SelectionDAG/ lib/Target/ARM/ lib/Target/X86/ lib/Target/XCore/ test/CodeGen/CellSPU/ test/CodeGen/Mips/ test/CodeGen/Thumb/ test/CodeGen/X86/

[Bruno Cardoso Lopes]

On Thu, Oct 27, 2011 at 11:29 PM, Dan Gohman <gohman at apple.com> wrote:
> Author: djg
> Date: Thu Oct 27 20:29:32 2011
> New Revision: 143177
>
> URL: http://llvm.org/viewvc/llvm-project?rev=143177&view=rev
> Log:
> Eliminate LegalizeOps' LegalizedNodes map and have it just call RAUW
> on every node as it legalizes them. This makes it easier to use
> hasOneUse() heuristics, since unneeded nodes can be removed from the
> DAG earlier.
>
> Make LegalizeOps visit the DAG in an operands-last order. It previously
> used operands-first, because LegalizeTypes has to go operands-first, and
> LegalizeTypes used to be part of LegalizeOps, but they're now split.
> The operands-last order is more natural for several legalization tasks.
> For example, it allows lowering code for nodes with floating-point or
> vector constants to see those constants directly instead of seeing the
> lowered form (often constant-pool loads). This makes some things
> somewhat more complicated today, though it ought to allow things to be
> simpler in the future. It also fixes some bugs exposed by Legalizing
> using RAUW aggressively.
>
> Remove the part of LegalizeOps that attempted to patch up invalid chain
> operands on libcalls generated by LegalizeTypes, since it doesn't work
> with the new LegalizeOps traversal order. Instead, define what
> LegalizeTypes is doing to be correct, and transfer the responsibility
> of keeping calls from having overlapping calling sequences into the
> scheduler.
>
> Teach the scheduler to model callseq_begin/end pairs as having a
> physical register definition/use to prevent calls from having
> overlapping calling sequences. This is also somewhat complicated, though
> there are ways it might be simplified in the future.
>
> This addresses rdar://9816668, rdar://10043614, rdar://8434668, and others.
> Please direct high-level questions about this patch to management.

As a reference, I believe this also fixes PR8156!

-- 
Bruno Cardoso Lopes
http://www.brunocardoso.cc