This is the mail archive of the gcc-patches@gcc.gnu.org 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" == Richard Sandiford <richard@codesourcery.com> writes:

 Richard> Ian Lance Taylor <ian@airs.com> 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> differently.

 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
for -Os.

    paul


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