On Jan 19, 2015, at 6:05 PM, Richard Earnshaw <rearn...@arm.com> wrote:
> On 16/01/15 15:06, Maxim Kuvyrkov wrote: >> @@ -1874,7 +1889,8 @@ const struct tune_params arm_cortex_a15_tune = >> true, true, /* Prefer 32-bit encodings. >> */ >> true, /* Prefer Neon for >> stringops. */ >> 8, /* Maximum insns to inline >> memset. */ >> - ARM_FUSE_NOTHING /* Fuseable pairs of >> instructions. */ >> + ARM_FUSE_NOTHING, /* Fuseable pairs of >> instructions. */ >> + max_insn_queue_index + 1 /* Sched L2 autopref depth. */ >> }; > > > Hmm, two issues here: > 1) This requires a static constructor for the tuning table entry (since > the value of max_insn_queue_index has to be looked up at run time. Are you sure? I didn't check the object files, but, since max_insn_queue_index is a "const int", I would expect a relocation that would be resolved at link time, not a constructor. Is it a problem to have a static constructor for the tables? > > 2) Doesn't this mean that the depth of searching will depend on > properties of the automata rather than some machine specific values (so > that potentially adding or removing unrelated scheduler rules could > change the behaviour of the compiler)? No. The extra queue entries that will appear from extending an unrelated automaton will be empty, so the search will check them, but won't find anything. > > In general, how should someone tuning the compiler for this parameter > select a value that isn't one of (-1, m_i_q_d+1)? >From my experiments it seems there are 4 reasonable values for the parameter: >(-1) autopref turned off, (0) turned on in rank_for_schedule, (m_i_q_d+1) >turned on everywhere. If there is a static constructor generated for tune >tables and it is a problem to have it -- I can shrink acceptable values to >these 3 and call it a day. -- Maxim Kuvyrkov www.linaro.org
