forked from OSchip/llvm-project
04365c5f72
The SRThreshold value makes perfect sense for checking if an entire aggregate should be promoted to a scalar integer, but it is not so good for splitting an aggregate into its separate elements. A struct may contain a large embedded array along with some scalar fields that would benefit from being split apart by SROA. Even if the total aggregate size is large, it may still be good to perform SROA. Thus, the most important piece of this patch is simply moving the aggregate size comparison vs. SRThreshold so that it guards only the aggregate promotion. We have also been checking the number of elements to decide if an aggregate should be split up. The limit of "SRThreshold/4" seemed rather arbitrary, and I don't think it's very useful to derive this limit from SRThreshold anyway. I've collected some data showing that the current default limit of 32 (since SRThreshold defaults to 128) is a reasonable cutoff for struct types. One thing suggested by the data is that distinguishing between structs and arrays might be useful. There are (obviously) a lot more large arrays than large structs (as measured by the number of elements and not the total size -- a large array inside a struct still counts as a single element given the way we do SROA right now). Out of 8377 arrays where we successfully performed SROA while compiling a large set of benchmarks, only 16 of them had more than 8 elements. And, for those 16 arrays, it's not at all clear that SROA was actually beneficial. So, to offset the compile time cost of investigating more large structs for SROA, the patch lowers the limit on array elements to 8. This fixes Apple Radar 7563690. llvm-svn: 95224 |
||
|---|---|---|
| clang | ||
| compiler-rt | ||
| llvm | ||