{"push_id":721136960,"size":1,"distinct_size":1,"ref":"refs/heads/master","head":"1406320ae67ed06f135a2068a0f6271665364cda","before":"f7b8f1cc3a290350b1cdbe86921bee864fdf35c8","commits":[{"sha":"1406320ae67ed06f135a2068a0f6271665364cda","author":{"email":"d72748a98fd8b476107003df407128e166d060ac@playingwithpointers.com","name":"Sanjoy Das"},"message":"[IndVars] Try to use existing values in RewriteLoopExitValues.\n\nSummary:\nIn RewriteLoopExitValues, before expanding out an SCEV expression using\nSCEVExpander, try to see if an existing LLVM IR expression already\ncomputes the value we're interested in.  If so use that existing\nexpression.\n\nApart from reducing IndVars' reliance on the rest of the compilation\npipeline, this also prevents IndVars from concluding some expressions as\n\"high cost\" when they're not.  For instance,\n`InductiveRangeCheckElimination` often emits code of the following form:\n\n```\nlen = umin(len_A, len_B)\n\nloop:\n  ...\n  if (i++ < len)\n    goto loop\n\noutside_loop:\n    use(i)\n```\n\n`SCEVExpander` refuses to rewrite the use of `i` in `outside_loop`,\nsince it thinks the value of `i` on loop exit, `len`, is a high cost\nexpansion since it contains an `umax` in it.  With this change,\n`IndVars` can see that it can re-use `len` instead of creating a new\nexpression to compute `umin(len_A, len_B)`.\n\nI considered putting this cleverness in `SCEVExpander`, but I was\nworried that it may then have a deterimental effect on other passes\nthat use it.  So I decided it was better to just do this in the one\nplace where it seems like an obviously good idea, with the intent of\ngeneralizing later if needed.\n\nReviewers: atrick, reames\n\nSubscribers: llvm-commits\n\nDifferential Revision: http://reviews.llvm.org/D10782","distinct":true,"url":"https://api.github.com/repos/llvm-project/llvm-project-submodule/commits/1406320ae67ed06f135a2068a0f6271665364cda"}]}