[LLVMdev] max/min intrinsics

Shuxin Yang shuxin.llvm at gmail.com
Wed Dec 5 10:34:30 PST 2012

Min/max certainly makes Loop Nest Optimization (including the innermost 
loop vectorization) lots easier.
However, I like they are "lowered" in lower level scalar opt (sopt).

I kinda feel "raw" instructions is bit easier than integrated 
instruction to optimized in sopt, and
the "raw" instruction could expose more opportunities.

e.g. In the following snippet,  if we break the max() into "raw" 
instruction, the cost of comparison
is reduced thanks to the CSE, and it also reveals that more often than 
not, Z hold value of min_v + 2.
However, max() obscure this info.
    if (min_v > max_v) {  // the branch is highly biased.

    t = max(min_v, max_v);
    z = t + 2;

Similar arguments for FMA formation, saturation add/sub recognition etc, 
etc etc...

IMHO, If some passes need to recognize these pattern, they are better 
proactively call some functions
to recognize them, and right after the passes lower them back to the 
"raw" form if the downstream
passes don't like these integrated instructions.

On 12/5/12 8:26 AM, Redmond, Paul wrote:
> I have been working on a patch to add support for max/min reductions in LoopVectorize. One of the comments that came up in review is that the implementation could be simplified (and less fragile) if max and min intrinsics were recognized rather than looking for compare-select sequences.
> The suggestion was to change compare-selects into max and min intrinsic calls during instcombine.
> The intrinsics to add are:
> declare iN llvm.{smin,smax}.iN(iN %a, iN %b)
> declare iN llvm.{umin,umax}.iN(iN %a, iN %b)
> declare fN llvm.{fmin,fmax}.fN(fN %a, fN %b)
> What does the community think?
> Paul
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

More information about the llvm-dev mailing list