This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH, midlevel]: Convert (int)floor -> lfloor
- From: Roger Sayle <roger at eyesopen dot com>
- To: Uros Bizjak <uros at kss-loka dot si>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Tue, 5 Apr 2005 09:06:45 -0600 (MDT)
- Subject: Re: [PATCH, midlevel]: Convert (int)floor -> lfloor
On Tue, 5 Apr 2005, Uros Bizjak wrote:
> However, there is no lfloor() or llfloor() function in libc. To overcome
> this problem, we look into machine instruction set and enable this
> transformation iff appropriate instruction is available (in addition to
> flag_unsafe_math_optimizations). This way, we won't fall back into
> (non-existing) library call.
If it's OK with you, I think I'd prefer to see this aspect of the patch
implemented slightly differently. Instead of tweaking mathfn_built_in
to return 0 if ever the backend doesn't support the optab, I think its
slightly preferrable to allow the middle-end (and GCC's front-ends) to
assume that these builtins exist, but then in expand_builtin lower them
to (int)floor(x) if expanding via the optab fails. This enables constant
folding and other transformations at the tree-ssa level to ignore any
potential target dependency.
This also works around issues such as the fact that this version of
the patch acknowledges the existance of these builtins even when
flag_unsafe_math_optimizations is not set (potentially creating problems
if ever a transformation tries generating one without -ffast-math),
and it also avoids problems with -msoft-float or -msse2 where just
because the target defines suitable patterns, doesn't mean that attempts
to use it will be successful.
Finally, I guess that you also plan to propose a symmetric pair of
patches for lceil and friends?
The approach itself looks good.