This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

Richard Sandiford <> writes:

> Ian Lance Taylor <> 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  Eric thought that would be a bad idea, because for
some programs it would introduce a library call where there wasn't one

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

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]