On Wed, 2018-08-15 at 12:45 +0200, Kai Tietz wrote: > > > I believe the scheduler provides hooks specifically for storing > > backend-specific scheduling state so we should > > avoid creating such static variables in aarch64.c. Can you use the > > TARGET_SCHED_*_SCHED_CONTEXT family of hooks here? > > Then it will be up to the scheduler midend to keep track of the > > state and > > between basic blocks, functions etc. > I think you refer to the ppc implementation. But if you take a closer > look to it, you will see that nevertheless such an implementation will > require global variables. > So I am not really sure it is worth to introduce the ..._SCHED_CONTEXT > API to avoid one global variable by introducing at least two others. > Neverthelss I am admit that making use of SCHED_CONTEXT could be a > general nice to have, but not necessarily a gain in that case.
I think having the SCHED_CONTEXT infrastructure could be helpful to me for Thunderx2. I am looking at an issue that I think TARGET_SCHED_VARIABLE_ISSUE will help with so having the general API available would be useful. I am looking at the lbm benchmark from SPEC and I believe it is overscheduling floating point instructions, if I cut the issue rate from 4 to 2, I get better performance on this one benchmark, but not on others. According to the Thunderx2 description, we can dispatch up to 4 uops per clock, but only up to 2 FP/SIMD uops. I know dispatch is different than issue but I don't think that GCC models both. For my patch I would probably want to save the previous instruction scheduled so that if it and the current one are both FP/SIMD ops, then that is all we can issue. I might need to save several instructions, not just the last one, to get everything correct. Steve Ellcey sell...@cavium.com
