[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