[PATCH] Cleanup / consolidation of small loop unroll logic

[Arnold Schwaighofer]

(CC'ed the list)

On Jan 28, 2014, at 8:08 PM, Chandler Carruth <chandlerc at gmail.com> wrote:

> 
> On Tue, Jan 28, 2014 at 7:57 PM, Arnold Schwaighofer <aschwaighofer at apple.com> wrote:
> 
>> This look OK? I just wanted to double check that there wasn't a specific reason to keep these two things separate. Hoping to get some good benchmarks on the new stuff you added soon.
>> 
> 
> I am a little concerned about this part:
> 
> +  if (!Legal->getRuntimePointerCheck()->Need &&
>       LoopCost < SmallLoopCost) {
> 
> This now guards all unrolling. We won’t unroll vectorized code if we need a runtime check where we did before. For example code that looks like the following snippet does not get unrolled.
> 
> int foo_func(float *A, float *B, int N) {
>  for (i in 0..N)
>    A[i] *= B[i];
> }
> 
> For optimal throughput we might want to unroll and vectorized this and we don’t mind the runtime check.
> 
> I wanted unrolling for load/stores ports to not create an extra runtime check if there wasn’t already one and so I had the "!Legal->getRuntimePointerCheck()->Need” guard. Initially this code was in the if (VF == 1) section. When I ported the patch this got lost.
> 
> Sure, makes sense. I didn't think of this only because I didn't see the VF==1, but the load/store heuristic I agree really only makes sense when we're unrolling unvectorized code.
> 
> Good to commit with that change?

LGTM.

> Do you want to add a test case for unrolling in the case of small vector code such as you describe? I suspect we're missing one.

I will add a test case tomorrow.

> 
> 
>> Also, unrelated, but can you commit the register pressure tweak yet? Still need more benchmarking?
> 
> Yes, this still needs benchmarking. If you want I can commit it behind a flag.
> 
> Flags are actually the easiest way for me to benchmark things -- it lets me just pick up an automated build of our toolchain and run it through with different flag


r200371.