[M3commit] CVS Update: cm3

[Jay K]

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