This is the mail archive of the
mailing list for the GCC project.
Re: PATCH RFA: Change MIPS ffs<mode>2 from define_insn to define_expand
>>>>> "Richard" == Richard Sandiford <email@example.com> writes:
Richard> Ian Lance Taylor <firstname.lastname@example.org> writes:
>> 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.
Richard> Yeah, for what it's worth, I largely agree. If it had been
Richard> up to me, I'd have been very open to your first idea of
Richard> dropping the patterns altogether.
Richard> If we do expand inline, I think it ought to be done
Richard> according to some sort of cost model. The current patterns
Richard> are trivially broken for -Os on mips*-elf because the call
Richard> sequence would be shorter than the inline loop. The
Richard> trade-offs for -O2 are more complex, and that's a good
Richard> reason why they shouldn't be duplicated (or ignored) by
Richard> backends. For example, in the presence of profile-directed
Richard> inlining, we might want to handle "cold" and "hot" calls
Richard> I'd consider it a bug that the ffs "optimisation" produces
Richard> strictly bigger code for -Os. And given that there's
Richard> nothing particularly MIPS-specific in what the patterns are
Richard> doing, I think that removing them is a good fix. Anyone who
Richard> believes that an inline loop should be used, and who's
Richard> sufficiently motivated to do it where it belongs, can do
Richard> that as a follow-on patch.
Ideally, the ffs pattern should take advantage of CLZ, if it exists on
the target. Then it clearly would be a win for -O2 and possibly even