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

[Jay K]

The reason it gets there is that multiple_of_p is true, because I'm dividing something by itself, in the test case.
The answer would be 1, unless the value is 0.

 - Jay

----------------------------------------
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu
> Date: Sat, 27 Nov 2010 00:14:24 +0000
> CC: m3devel at elegosoft.com
> Subject: [M3devel] fold_build(divide) vs. build(divide)
>
>
> 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.
> > > >>>
> > > >>
> > >
>