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: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
CC: [email protected]
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.
_______________________________________________
LLVMbugs mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/llvmbugs
