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
This commit is contained in:
Tom Stellard 2014-02-25 21:36:21 +00:00
parent d8c31046a9
commit 431e9f0310

View File

@ -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;
}
}
}