[M3devel] fold_build(divide) vs. build(divide)

[Jay K]

I don't know what the strong/weak casts are, but here is the problem seemingly:

gcc-4.5
fold-const.c

fold_binary_loc(code = FLOOR_DIV_EXPR,
                op0, op1, type all int_64

arg0, arg1 become word_64
(not op0, op1, but arg0, arg1)

and then we end up here:

      if ((code == CEIL_DIV_EXPR || code == FLOOR_DIV_EXPR)
      && multiple_of_p (type, arg0, arg1))
    return fold_build2_loc (loc, EXACT_DIV_EXPR, type, arg0, arg1);

and then, configure -enable-checking=fold,...:

error: type mismatch in binary expression
int_64

word_64

word_64

D.1003 = D.1001 /[ex] D.1002;

I'll maybe see if newer gcc is different or open a bug or discuss on gcc at .

 - Jay


----------------------------------------
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu
> Date: Tue, 23 Nov 2010 22:50:02 +0000
> CC: m3commit at elegosoft.com
> Subject: Re: [M3commit] CVS Update: cm3
>
>
> Aha. I had no idea and should investigate further.
> Notice though that I've been applying the same sorts of casts
> everywhere and they generally help. But perhaps they are
> weak, and weak is usually strong enough, or some such.
> Almost anything is possible. :)
>
>
> - Jay
>
>
>
> ----------------------------------------
> > Subject: Re: [M3commit] CVS Update: cm3
> > From: hosking at cs.purdue.edu
> > Date: Tue, 23 Nov 2010 17:47:16 -0500
> > CC: m3commit at elegosoft.com
> > To: jay.krell at cornell.edu
> >
> > There are weak and strong casts in gcc.
> > I forget the precise details, but I believe they will make a difference.
> >
> >
> > Antony Hosking | Associate Professor | Computer Science | Purdue University
> > 305 N. University Street | West Lafayette | IN 47907 | USA
> > Office +1 765 494 6001 | Mobile +1 765 427 5484
> >
> >
> >
> >
> > On Nov 23, 2010, at 4:51 PM, Jay K wrote:
> >
> > >
> > > But I did that, or maybe they were already there, and it seem/seemed to help in general, but not for divide.
> > > Presumably fold is removing the cast somewhere.
> > > Maybe a gcc bug???
> > > I can dig deeper if you really want.
> > >
> > >
> > > Or maybe they didn't make a difference and I put them in wrong and divide is the only
> > > preexisting problem. I'd have to double check. Sorry, about the lack of certainty..
> > > (certainly casts were needed in general in a few places, but I don't remember specifically for plus/minus/mult/divide).
> > >
> > >
> > > I actually find it odd that build_fold is even a public heavily used function.
> > > It seems to me it should be, like, done at the next level down.
> > >
> > >
> > > Which reminds me, in load/store, if the two types are both integers and the same size
> > > but different in signedness, I want to try *not* taking the address.
> > > Probably also for pointer<=>integer of pointer size.
> > > Though this is "short term", since the address-taking should go away *eventually* by other means (component_ref/array_ref), though realistically, that's a ways off..
> > >
> > >
> > > - Jay
> > >
> > >
> > > ________________________________
> > >> From: hosking at cs.purdue.edu
> > >> Date: Tue, 23 Nov 2010 16:38:39 -0500
> > >> To: jay.krell at cornell.edu
> > >> CC: m3commit at elegosoft.com
> > >> Subject: Re: [M3commit] CVS Update: cm3
> > >>
> > >> That should be handled by placing an appropriate cast in the gcc tree.
> > >>
> > >> On Nov 23, 2010, at 1:45 PM, Jay K wrote:
> > >>
> > >> Try building m3-sys/m3tests/p2/p240.
> > >> There is an error in the configure enable-checking about the types
> > >> being mismatched.
> > >>
> > >> - Jay
> > >>
> > >>
> > >>> From: hosking at cs.purdue.edu
> > >>> Date: Tue, 23 Nov 2010 09:48:19 -0500
> > >>> To: jkrell at elego.de
> > >>> CC: m3commit at elegosoft.com
> > >>> Subject: Re: [M3commit] CVS Update: cm3
> > >>>
> > >>>
> > >>> On Nov 23, 2010, at 10:49 AM, Jay Krell wrote:
> > >>>
> > >>>> CVSROOT: /usr/cvs
> > >>>> Changes by: jkrell at birch. 10/11/23 10:49:57
> > >>>>
> > >>>> Modified files:
> > >>>> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c
> > >>>>
> > >>>> Log message:
> > >>>> Go with the obvious less heavy handed fix of only avoiding
> > >>>> fold for integer division.
> > >>>
> > >>> I don't understand what the issue is with folding on integer
> > >> division. Please explain.
> > >>>
> > >>>> This is enough for test p240 and the unoptimized code is definitely
> > >> better.
> > >>>> NOT fully tested, but really probably works.
> > >>>> It is probably worth digging into the frontend to see if there is a
> > >> difference
> > >>>> in the types. It is probably also worth digging in the backend, like,
> > >>>> we do put in the casts consistently, why are they only not effective
> > >>>> for divide? I realize that a little bit of analysis goes a long way
> > >>>> on many divide cases: "divide tends to produce small results", sort of.
> > >>>> On the other hand, it isn't worth too much effort.
> > >>>> Divide is the slowest least used integer operation.
> > >>>
> > >>
> >