[PATCH] Cleanup / consolidation of small loop unroll logic

Chandler Carruth chandlerc at gmail.com
Tue Jan 28 20:08:46 PST 2014


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? 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.


> > 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 flags.

-Chandler
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140128/aa0fd73f/attachment.html>


More information about the llvm-commits mailing list