R600: Don't unconditionally unroll loops with private memory accesses

This causes the size of the scrypt kernel to explode and eats all the
memory on some systems.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202195 91177308-0d34-0410-b5e6-96231b3b80d8

diff --git a/lib/Target/R600/AMDGPUTargetTransformInfo.cpp b/lib/Target/R600/AMDGPUTargetTransformInfo.cpp
index 7f37658371d65c6a7494b9d8df911b350939fa3b..9cdfec59412052fbf0c41a3372f67e360c0e84aa 100644 (file)
--- a/lib/Target/R600/AMDGPUTargetTransformInfo.cpp
+++ b/lib/Target/R600/AMDGPUTargetTransformInfo.cpp
@@ -110,9 +110,13 @@ void AMDGPUTTI::getUnrollingPreferences(Loop *L,
         // instructions that make it through to the code generator.  allocas
         // require us to use indirect addressing, which is slow and prone to
         // compiler bugs.  If this loop does an address calculation on an
-        // alloca ptr, then we want to unconditionally unroll the loop.  In most
-        // cases, this will make it possible for SROA to eliminate these allocas.
-        UP.Threshold = UINT_MAX;
+        // alloca ptr, then we want to use a higher than normal loop unroll
+       // threshold.  This will give SROA a better chance to eliminate these
+       // allocas.
+       //
+       // Don't use the maximum allowed value here as it will make some
+       // programs way too big.
+        UP.Threshold = 500;
       }
     }
   }