[llvm-commits] [llvm][PATCH][Review Requested] Maintain live-ins for anti-dependency checking [Take 2]

Jakob Stoklund Olesen stoklund at 2pi.dk
Mon Apr 16 14:49:01 PDT 2012


On Apr 16, 2012, at 2:43 PM, "Gurd, Preston" <preston.gurd at intel.com> wrote:

> This patch fixes a problem which arose when using the Post-RA scheduler on X86 Atom. Some of our tests failed because the tail merging part of the BranchFolding pass was creating new basic blocks which did not contain live-in information. When the anti-dependency code in the Post-RA scheduler ran, it would sometimes rename the register containing the function return value because the fact that the return value was live-in to the subsequent block had been lost. To fix this, it is necessary to run the RegisterScavenging code in the BranchFolding pass.
>  
> This patch makes sure that the register scavenging code is invoked in the X86 subtarget only when post-RA scheduling is being done. Post RA scheduling in the X86 subtarget is only done for Atom.
>  
> This patch adds a new function to the TargetRegisterClass to control whether or not live-ins should be preserved during branch folding. This is necessary in order for the anti-dependency optimizations done during the PostRASchedulerList pass to work properly when doing Post-RA scheduling for the X86 in general and for the Intel Atom in particular.
>  
> The patch adds and invokes the new function  trackLivenessAfterRegAlloc() instead of using the existing requiresRegisterScavenging(). It changes BranchFolding.cpp to call trackLivenessAfterRegAlloc() instead of requiresRegisterScavenging(). It changes the all the targets that implemented requiresRegisterScavenging() to also implement trackLivenessAfterRegAlloc().  
>  
> It adds an assertion in the Post RA scheduler to make sure that post RA liveness information is available when it is needed.
>  
> It changes the X86 break-anti-dependencies test to use –mcpu=atom, in order to avoid running into the added assertion.
>  
> Please review!

LGTM. Anton?

/jakob

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


More information about the llvm-commits mailing list