Re: PATCH RFA: Change MIPS ffs<mode>2 from define_insn to define_expand

[Ian Lance Taylor <ian at airs dot com>]

Richard Sandiford <richard@codesourcery.com> writes:

> Ian Lance Taylor <ian@airs.com> writes:
> > Of course, it would be even better if we expanded earlier, into trees,
> > so that the instructions were exposed to the tree optimizers.  And for
> > that matter this code is essentially generic and not really MIPS
> > specific at all.
> 
> The second sentence is why I don't think this patch is a good idea.  I
> don't want to see us add new target-independent expansions to the MIPS
> backend.  If you want to change the way that ffs is implemented, please
> either provide this expansion in the tree->rtl expanders or do it as
> a tree-level reduction in the way you suggest.

What I originally wanted to do was to simply eliminate the ffs<mode>2
insn from mips.md.  Eric thought that would be a bad idea, because for
some programs it would introduce a library call where there wasn't one
before.

I don't actually think it's a good idea to expand ffs inline into a
loop.  I don't think that is a choice the compiler should be making,
so I don't think it is really appropriate to do it in generic code.
As far as I know we do not currently expand any other builtin
functions into loops.

So given the decisions 1) I can't eliminate ffs<mode>2, and 2) I don't
think it is appropriate for generic code, the end result was the patch
that I wrote, which is at least an improvement on the current
situation.

I'm willing to write a generic patch to expand ffs into an inline loop
in builtins.c or optabs.c, but first I'd like to hear from some
general maintainers as to whether that seems like a good approach.

Ian