[llvm-commits] [PATCH] Stack Coloring optimization

James Molloy James.Molloy at arm.com
Mon Sep 3 07:02:09 PDT 2012


Hi Nadav,

Just to confirm, you are talking about the scheduler stuff Jakob talked
about, right?

Cheers,

James

On Mon, 2012-09-03 at 14:57 +0100, Nadav Rotem wrote:
> Hi James,
>
> This code works after ISel and does not reorder loads and stores.   It's still not in the trunk.
>
> Nadav
>
> On Sep 3, 2012, at 4:47 PM, 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?
> >
> > 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
> >>
> >
> >
> >
>
>
>


-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium.  Thank you.




More information about the llvm-commits mailing list