[LLVMbugs] [Bug 2611] New: smax scev is redundant with umax

[bugzilla-daemon at cs.uiuc.edu]

http://llvm.org/bugs/show_bug.cgi?id=2611

           Summary: smax scev is redundant with umax
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: sharparrow1 at yahoo.com
                CC: llvmbugs at cs.uiuc.edu


Per discussion with nicholas on IRC, the SMAX and UMAX scevs are redundant; "a
smax b" can be rewritten as "((a + INT_MIN) umax (b + INT_MIN)) + INT_MIN".

Quick explanation of the reasoning: the range of signed integers is from
INT_MIN to INT_MAX.  The range of unsigned integers is from 0 to UINT_MAX.  By
adding INT_MIN to a number, it is mapped from the signed integer range to the
unsigned integer range in the correct order.  Then, the umax returns the larger
number, and then adding INT_MIN again restores the result into the range of
signed numbers.

For implementation, the idea is mostly straightforward: just replace
getSMaxExpr with a getSMaxSCEV which does this mapping.  The subtle point is
not getting any regressions in code quality.  The ScalarEvolutionExpander
probably should be made a bit smarter, and instcombine probably should be made
smart enough to deal with expressions like this (currently, instcombine can't
fold the naive expansion at all).

2's complement arithmetic and comparisons is so much fun.  Good way to make
your head spin. :)


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.