This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [4.3] fix c/39902 for decimal float constant folding
On Fri, 2009-07-17 at 11:05 +0200, Richard Guenther wrote:
> On Thu, Jul 16, 2009 at 8:09 PM, Janis Johnson<janis187@us.ibm.com> wrote:
> > On Thu, 2009-07-16 at 10:03 -0700, Janis Johnson wrote:
> >> On Thu, 2009-07-16 at 10:49 +0200, Richard Guenther wrote:
> >> > On Thu, Jul 16, 2009 at 1:27 AM, Janis Johnson<janis187@us.ibm.com> wrote:
> >> > > On Wed, 2009-07-15 at 23:21 +0200, Richard Guenther wrote:
> >> > >> On Wed, Jul 15, 2009 at 11:14 PM, Janis Johnson<janis187@us.ibm.com> wrote:
> >> > >> > In http://gcc.gnu.org/ml/gcc-patches/2009-06/msg02044.html, Richard
> >> > >> > Guenther approved a version of this patch for trunk and the branches.
> >> > >> > The mainline patch works for the 4.4 branch but not 4.3, where there
> >> > >> > are additional passes that do constant folding. This patch disables
> >> > >> > RTL constant folding for binary operations involving decimal float
> >> > >> > constants.
> >> > >>
> >> > >> I'd rather have the trunk bits that fixed it there backported than putting
> >> > >> a check on the branch that is not on trunk. Why doesn't trunk need the
> >> > >> simplify-rtx.c hunk?
> >> > >>
> >> > >> Richard.
> >> > >
> >> > > The changes to tree.c are the same as in the trunk. In the 4.3
> >> > > branch the call to simplify_binary_operation that does this
> >> > > particular constant folding comes through dead_libcall_p, a
> >> > > function that no longer exists in 4.4 and later.
> >> >
> >> > I see. So you are comfortably sure all other places that call
> >> > simplify-rtx are properly guarded in trunk? At least I cannot see
> >> > how wrong simplifications are avoided in simplify_binary_operation_1
> >> > there. Which would be the better place to stick you check so
> >> > that constant folding via dfp.c can still be performed from
> >> > simplify_const_binary_operation?
> >> >
> >> > Thanks,
> >> > Richard.
> >>
> >> No, I'm not comfortable, and while trying to avoid a libcall to
> >> multiply a decimal float value by -1.0dd with negating the value
> >> (which isn't valid for decimal float arithmetic, where trailing
> >> zeroes are significant) I now see that I went too far and turned
> >> off some legitimate (for decimal float) constant folding.
> >>
> >> Probably what I really want to do is prevent generating the REG_EQUAL
> >> note that causes the replacement in the 4.3 branch. The REG_EQUAL is
> >> also generated for trunk and 4.4, but without the call to
> >> dead_libcall_p it's not being replaced in those versions, at least
> >> for this particular test case; it might cause problems elsewhere.
> >
> > Never mind, I found the optimization in simplify_binary_operation_1:
> >
> > case MULT:
> > if (trueop1 == constm1_rtx)
> > return simplify_gen_unary (NEG, mode, op0, mode);
> >
> > There are similar optimizations there, in trunk as well, that are
> > not valid for decimal float arithmetic.
>
> Yes. The changes that are already there on trunk are ok for the
> branch btw (just in case you want to commit them separately).
I found the real problem in the 4.3 branch, later in that same function.
It affects trunk and 4.4 with "-O2 -mhard-dfp", so I'll fix it in trunk
first and then ask to backport that to 4.4 and both parts of the fix to
4.3.
Janis