Add ops_num to targetm.sched.reassociation_width hook

Add ops_num to targetm.sched.reassociation_width hook

[Aaron Sawdey]

Richard,

So, I’m noticing that in get_reassociation_width() we know how many ops (ops_num) are in the expression being considered for parallel reassociation, but this is not passed to the target hook. In my testing this seems like it might be useful to have. If you determine the maximum width that gives additional speedup for a large number of terms, and then use that as the width from the target hook, get_reassociation_width() is more aggressive than you would like for small expressions with maybe 4-16 terms and produces code that is slower than optimal. For example in many cases you want to continue using a width of 1 until you get to 16 terms or so. My testing shows this to be the case for power8, power9, and power10 processors. 

So, I’m wondering how it might be received if I posted a patch that adds this to the reassociation_width target hook (and of course fixes all uses of that target hook)?

Thanks!
   Aaron


Aaron Sawdey, Ph.D. sawdey@linux.ibm.com
IBM Linux on POWER Toolchain
 

Re: Add ops_num to targetm.sched.reassociation_width hook

[Richard Biener]

On Wed, Aug 4, 2021 at 2:07 AM Aaron Sawdey <acsawdey@linux.ibm.com> wrote:
>
> Richard,
>
> So, I’m noticing that in get_reassociation_width() we know how many ops (ops_num) are in the expression being considered for parallel reassociation, but this is not passed to the target hook. In my testing this seems like it might be useful to have. If you determine the maximum width that gives additional speedup for a large number of terms, and then use that as the width from the target hook, get_reassociation_width() is more aggressive than you would like for small expressions with maybe 4-16 terms and produces code that is slower than optimal. For example in many cases you want to continue using a width of 1 until you get to 16 terms or so. My testing shows this to be the case for power8, power9, and power10 processors.
>
> So, I’m wondering how it might be received if I posted a patch that adds this to the reassociation_width target hook (and of course fixes all uses of that target hook)?

You probably saw that get_reassociation_width already tries to
optimize things.  So what exactly
would you change and why is it slower for 4-16 terms but not for 17+
ones?  I suppose "is slower"
is --param mining on some benchmarks on your side and eventually you
manage to pick the
best threshold to not run into register pressure issues (by luck) for
those benchmarks?

That said, I question you can explain why it is slower, right?

Richard.

> Thanks!
>    Aaron
>
>
> Aaron Sawdey, Ph.D. sawdey@linux.ibm.com
> IBM Linux on POWER Toolchain
>
>