[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