[M3commit] CVS Update: cm3

[Jay K]

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