[llvm-commits] [PATCH] Stack Coloring optimization

Hal Finkel hfinkel at anl.gov
Mon Sep 3 09:38:15 PDT 2012


On Mon, 03 Sep 2012 14:47:59 +0100
James Molloy <james.molloy at arm.com> wrote:

> Hi,
> 
> I'm interested in this; is this code in trunk at the moment?
> 
> I've been working on an optimisation to put non-aliasing loads and
> stores on different chains during selectiondag creation - is this
> scheduler code supposed to reorder independent loads and stores?

James,

Is this different from the patch I proposed last year?

 -Hal

> 
> Cheers,
> 
> James
> 
> On Thu, 2012-08-30 at 19:57 +0100, Jakob Stoklund Olesen wrote:
> > On Aug 30, 2012, at 2:51 AM, Nadav Rotem <nrotem at apple.com> wrote:
> > 
> > > Hi All, 
> > > 
> > > I've been working on a new optimization for reducing the stack
> > > size.  Currently, when we declare allocas in LLVM IR, these
> > > allocas are directly translated to stack slots. And when we
> > > inline small functions into larger function, these allocas add up
> > > and take up lots of space.  In some cases we know that the use of
> > > the allocas is bounded by disjoint regions.  In this optimization
> > > we merge multiple disjoint slots into a single slot.  LLVM uses
> > > the lifetime markers for specifying the regions in which the
> > > allcoa is used.  This patch propagates the lifetime markers
> > > through SelectionDAG and makes them pseudo ops.  Later, a
> > > pre-register-allocator pass constructs live intervals which
> > > represent the lifeless of different stack slots. Next, the pass
> > > merges disjoint intervals.  Notice that lifetime markers and not
> > > perfect single-entry-single exit regions. They may be removed by
> > > optimizations, they may start with two markers, and end with one,
> > > or even not end at all! 
> > > 
> > > So, why is this done in codegen?  There are a number of reasons.
> > > First, joining allocas may hinder alias analysis. Second, in the
> > > future we would like to share the alloca space with spill slots.
> > 
> > About alias analysis. Andy was just showing me the scheduler's AA
> > code. It is using the memory operands to find the underlying LLVM
> > IR object. Loads and stores to different allocas are partitioned
> > according to their underlying IR object.
> > 
> > Merging stack slots before the MI scheduler could invalidate this
> > form of alias analysis since two IR allocas can share a stack slot.
> > 
> > /jakob
> > 
> > _______________________________________________
> > llvm-commits mailing list
> > llvm-commits at cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
> > 
> 
> 
> 
> 
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits



-- 
Hal Finkel
Postdoctoral Appointee
Leadership Computing Facility
Argonne National Laboratory



More information about the llvm-commits mailing list