[LLVMdev] some superoptimizer results

[Hal Finkel]

One thing that is important to consider is where in the pipeline these kinds of optimizations fit. We normally try to put the IR into a canonical simplified form in the mid-level optimizer. This form is supposed to be whatever is most useful for exposing other optimizations, and for lowering, but only in a generic sense. We do have some optimizations near the end of our pipeline (vectorization, partial unrolling, etc.) that consider target-specific properties, but only because the alternative is doing those loop optimizations after instruction selection.

Considering ILP and other pipeline-level costs are something we generally consider only in the SelectionDAG and after. If these are IR optimizations, then I'm not sure that considering ILP, etc. is the right metric -- so long as the transformations are sufficiently reversible to allow of efficient lowering afterward.

 -Hal

----- Original Message -----
> From: "Sean Silva" <chisophugis at gmail.com>
> To: "John Regehr" <regehr at cs.utah.edu>
> Cc: llvmdev at cs.uiuc.edu
> Sent: Wednesday, July 22, 2015 2:35:51 PM
> Subject: Re: [LLVMdev] some superoptimizer results
> 
> 
> 
> Are you taking into account critical path length? Because e.g. for:
> 
> 
> 
> %0:i64 = var
> %1:i1 = slt 18446744073709551615:i64, %0
> %2:i64 = subnsw 0:i64, %0
> %3:i64 = select %1, %0, %2
> infer %3
> %4:i64 = ashr %0, 63:i64
> %5:i64 = add %0, %4
> %6:i64 = xor %5, %4
> result %6
> 
> 
> In the former case, the cmp and sub are independent, so can be
> executed in parallel, while in the latter case all 3 instructions
> are dependent. So the former case can execute in 2 cycles while the
> latter takes 3. Modern OoO chips do in fact exploit this kind of
> thing.
> 
> 
> -- Sean Silva
> 
> 
> 
> 
> On Wed, Jul 22, 2015 at 10:15 AM, John Regehr < regehr at cs.utah.edu >
> wrote:
> 
> 
> We (the folks working on Souper) would appreciate any feedback on
> these IR-level superoptimizer results:
> 
> http://blog.regehr.org/extra_files/souper-jul-15.html
> 
> My impression is that while there's clearly plenty of material in
> here that doesn't want to get implemented in an opt pass, there are
> a number of gems hiding in there that are worth implementing.
> 
> Blog post containing additional explanation and caveats is here:
> 
> http://blog.regehr.org/archives/1252
> 
> Thanks!
> 
> John
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory