Re: [patch, rfc] add case-values-threshold as a param

[Roger Sayle <roger at eyesopen dot com>]

On Tue, 12 Oct 2004, Eric Christopher wrote:
> This changes it from a #define to a parameter - but only if the backend
> hasn't already defined it. The only functional difference here is that I
> was unable to keep the conditional on HAVE_casesi to determine the
> default value so I left it at 6, unless someone has an idea there. I was
> trying to keep the changes minimal.
>
> Thoughts? OK?

A couple of suggestions.

Firstly, the text description of this parameter is misleading/incorrect.
The parameter is not the "maximum number of values in a case statement"!
I'm fairly sure GCC can handle switches with as many as eight or nine
values  :>  Instead it is the "minimum number of values implemented by a
jump table".  A switch statement with less than this number of values
will always use a sequence/tree of conditional branches.


Secondly, I think it should be possible to use this parameter to
override the backend's default, and still preserve the current
HAVE_casei behaviour.

The only place that CASE_VALUES_THRESHOLD is used is in expr.c's
case_values_threshold.  Which may be rewritten as:

unsigned int
case_values_threshold (void)
{
  unsigned int result;

  result = PARAM_VALUE (PARAM_CASE_VALUE_THRESHOLD);
  if (result > 1)
    return result;
#ifdef CASE_VALUES_THRESHOLD
  return CASE_VALUES_THRESHOLD
#else
  return HAVE_casesi ? 4 : 5;
#endif
}

A value of less than or equal to 1 for PARAM_CASE_VALUE, which should
include the default, perhaps -1 (or 0, or 1), indicates that the usual
default should be used.  Values larger than this can then be used to
tune this threshold, even on backends that provide their own defaults.


Penultimately, I'd also be cautious about changing this value to "6"
without a lot more benchmarking than described in your post.  [A bootstrap
and regression test would be a good start :>  I know, you were just asking
for feedback, but a value of 5 would minize any potential fallout].

Finally, this parameter is sensitive to how well we implement switch
statements as conditional branches.  One trivial improvement is that
for sets of less than three or four case values, we're better off using
a sequential run of tests instead of the current binary tree.  Clearly,
if this issue were ever to be addressed the break-even point may shift
yet again.


What do you think?


Roger
--