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.<br>
<div><br></div><div>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?</div>
<div><br></div><div>Thanks!</div><div><br></div><div>-eric</div><br><div>On Wed Jan 22 2014 at 6:07:40 PM, Robinson, Paul <<a href="mailto:Paul_Robinson@playstation.sony.com">Paul_Robinson@playstation.sony.com</a>> wrote:</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-US" link="blue" vlink="purple">
<div>
<p><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">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.<u></u><u></u></span></p>
<p><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Thanks,<u></u><u></u></span></p>
<p><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">--paulr<u></u><u></u></span></p>
<p><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0in 0in 0in">
<p><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> <a href="mailto:llvm-commits-bounces@cs.uiuc.edu" target="_blank">llvm-commits-bounces@cs.uiuc.edu</a> [mailto:<a href="mailto:llvm-commits-bounces@cs.uiuc.edu" target="_blank">llvm-commits-bounces@cs.uiuc.edu</a>]
<b>On Behalf Of </b>Juergen Ributzka<br>
<b>Sent:</b> Wednesday, January 22, 2014 5:32 PM<br>
<b>To:</b> LLVM Commits; Owen Anderson<br>
<b>Subject:</b> [PATCH] Constant Hoisting Pass<u></u><u></u></span></p>
</div>
</div></div></div></div><div lang="EN-US" link="blue" vlink="purple"><div><div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<p><u></u> <u></u></p>
<div>
<div>
<p style="margin-bottom:12.0pt"><span style="font-size:10.0pt">Hi @ll,<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Thanks for any review in advance.<br>
<br>
Cheers,<br>
Juergen<u></u><u></u></span></p>
</div>
</div>
<div>
<div>
<p><span style="font-size:10.0pt">_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@cs.uiuc.edu" target="_blank">llvm-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><u></u><u></u></span></p>
</div>
</div>
</div></div></div></blockquote>