[PATCH] Constant Hoisting Pass

[Eric Christopher]

It's actually hard to create debug info for materializing constants in
selection dag, but it is possible - unfortunately a lot of work to do so. I
had a prototype patch to take the debug loc of an instruction and add it to
the moved/materialized constant; after 400k of patch I said "git stash" and
haven't gotten back to it yet.

That said, this will only be turned on in the presence of optimization (I
imagine) though we'd probably like some debug loc associated with it.
Perhaps the earliest such location. Juergen: could you make sure that while
you might not make attaching the debug loc any easier that you haven't made
it any harder with this pass?

Thanks!

-eric

On Wed Jan 22 2014 at 6:07:40 PM, Robinson, Paul <
Paul_Robinson at playstation.sony.com> wrote:

>  With this kind of thing, I get concerned that moving stuff around will
> cause unnecessary chaos with debug info.  But it looks like the new
> instructions you’re creating don’t have a source location attached?  In
> this case that’s probably the right thing to do.  Let me know if I’m
> misunderstanding what’s going on here.
>
> Thanks,
>
> --paulr
>
>
>
> *From:* llvm-commits-bounces at cs.uiuc.edu [mailto:
> llvm-commits-bounces at cs.uiuc.edu] *On Behalf Of *Juergen Ributzka
> *Sent:* Wednesday, January 22, 2014 5:32 PM
> *To:* LLVM Commits; Owen Anderson
> *Subject:* [PATCH] Constant Hoisting Pass
>
>
>
> Hi @ll,
>
> this set of patches add a new pass called constant hoisting to the codegen
> pipeline. The idea behind this pass is to hoist and hide expensive
> constants, which forces them to be live-out/live-in of/into the basic
> block. This is done to work around the one-basic-block-a-time approach of
> SelectionDAG and friends. The intention is to prevent materialization of
> expensive integer constants in every single basic block and to keep them
> instead in registers. This pass sounds extremely like a CodeGenPrepare
> pass, but I had to spilt it out into a separate pass that just runs right
> before CodeGenPrepare. The reason for this is the horribly broken update
> code for the dominator tree in CodeGenPrepare. Luckily this code is
> currently dead, because the dominator tree is never available during
> CodeGenPrepare.
>
> This pass will be extremely beneficial for JavaScript code, because it
> uses a lot of 64bit constants. I also tested it with the llvm test-suite,
> but it didn’t show a big change there. Interestingly I didn’t see any
> compile time increase. I actually have a few benchmarks that show a
> decrease in compile time in the 1-2% range, but that could also be just
> noise. Currently this pass will only affect X86, because that is the only
> target that implements the required target hooks. Other targets shouldn’t
> see any change.
>
> The first patch simply updates TargetTransformInfo subclasses with the
> override and final keywords. Interestingly the method “finalizePass” is
> never called nor overrides a method from a base class.
>
> The second patch extends TargetTransformInfo with additional target hooks
> for immediate costs, the constant hoisting pass, and the extensions to
> SelectionDAG for opaque constants. More details are in the attached patch.
>
> Thanks for any review in advance.
>
> Cheers,
> Juergen
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140123/9fa308b4/attachment.html>