On Tue, 16 Feb 2021, Jeff Law via Gcc-patches wrote:
> > diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
> > index 4c38244ae58..6b9520569ba 100644
> > --- a/gcc/doc/install.texi
> > +++ b/gcc/doc/install.texi
> > @@ -1464,6 +1464,29 @@ systems that support conditional traps).
> > Division by zero checks use the break instruction.
> > @end table
> >
> > +@item --with-compact-branches=@var{policy}
> > +Specify how the compiler should generate code for checking for
> > +division by zero. This option is only supported on the MIPS target.
> > +The possibilities for @var{type} are:
> Is this really correct -- I would expect that the change affects
> branches in general, not just checks for division by zero.
I wonder if we need to multiply the options here at all. The original
change: <https://gcc.gnu.org/ml/gcc-patches/2015-07/msg01892.html> was
discussed here: <https://gcc.gnu.org/ml/gcc-patches/2015-08/msg00940.html>
in this respect:
On Mon, 17 Aug 2015, Matthew Fortune wrote:
> > > Compact branches are used based on a branch policy. The polices are:
> > >
> > > never: Only use delay slot branches
> > > optimal: Do whatever is best for the current architecture. This will
> > > generally mean that delay slot branches will be used if the delay
> > > slot gets filled but otherwise a compact branch will be used. A
> > > special case here is that JAL and J will not be used in R6 code
> > > regardless of whether the delay slot could be filled.
> > > always: Never emit a delay slot form of a branch if a compact form exists.
> > > This policy cannot apply 100% as FP branches (and MSA branches
> > > when
> > > committed) only have delay slot forms.
> > >
> > > These user choices are combined with the features available in the chosen
> > > architecture and, in particular, the optimal form will get handled like
> > > 'never' when there are no compact branches available and will get handled
> > > like 'always' when there are no delay slot branches available.
> > >
> >
> > Why did you choose to make this a user-selectable option? Why not always
> > generated
> > optimal?
> > I don't have a strong opinion about it, but the options seem to complicate
> > things and I'm
> > interested in your rationale.
>
> This is down to micro-architecture decisions that different implementers may
> make.
> Honestly, I have not absorbed all of the rationale behind choosing one form
> over
> the other but our arch team have made enough comments about this to mean the
> support
> in the compiler is worth the extra bit of effort. I can attempt a write-up of
> some
> of the pipeline possibilities if you would like more detail but I'd probably
> have to
> refresh my mind on this with our hardware teams.
My understanding therefore is that the original assumption that `optimal'
will serve people best is no longer true.
First, I think it would be good if we knew why. I find proliferating
variants of defaults, especially for the less obvious cases, will cause
user confusion as one won't know what code model to expect, especially as
(please correct me if I am wrong) we don't actually provide a way to dump
the compiler's overridable configuration defaults.
Second, I wonder if it makes sense to just keep things simple, and rather
than adding `prefer' (to stand for "`always' if available"), and possibly
`avoid' (to stand for "`never' if available"), whether we shouldn't just
relax the checks for `always' and `never', and let them through whether
the architecture selected provides for the option chosen or not.
Please note that in the discussion quoted Catherine has already raised a
concern I agree with of adding a complication here, and now we would
complicate it even further by not only adding a fourth choice, but another
overridable configuration default as well.
Maciej
