[M3commit] CVS Update: cm3

Tony Hosking hosking at cs.purdue.edu
Tue Nov 23 23:47:16 CET 2010


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




More information about the M3commit mailing list