[M3devel] aliases/optimization

[Tony Hosking]

I thought I already implemented one of those.

On 4 Jul 2010, at 04:14, Jay K wrote:

> 
> It appears this behavior is part of the C frontend, not the backend.
> It appears..that maybe..we should provide a langhook get_alias_set that always returns 0.
> The default is always -1.
> Not clear to me.
> 
>  - Jay
> 
> ----------------------------------------
>> From: jay.krell at cornell.edu
>> To: hosking at cs.purdue.edu
>> CC: m3devel at elegosoft.com
>> Subject: aliases/optimization
>> Date: Sun, 4 Jul 2010 01:16:23 +0000
>> 
>> 
>> aha you just reminded me of something that we need to remember a bit and apply soon.
>> 
>> 
>> Depending on compilers, optimization, etc. gcc doesn't like:
>> 
>> 
>> float f;
>> int i;
>> i = *(int*)&f;
>> 
>> though I think that's perfectly reasonable..anyway the equivalent form of code that gcc is explicitly ok with is:
>> 
>> float f;
>> 
>> int i;
>> union {
>>  float f;
>>  int i;
>> } u;
>> u.f = f;
>> i = u.i;
>> 
>> So, point being, we should try changing LOOPHOLE to compile like that.
>> You know, cons up the union type on-demand, make a local, etc.
>> 
>> If we are lucky, that might solve some of our problems.
>> Not the PPC ones.
>> But that I left some systematic use of volatile in, like for all floating point, or something.
>> And maybe it'll fix some of the optimizations I disabled.
>>  It'd still leave "unit at a time" broken.
>>  Possibly in tree-nested we can remove any notion of the functions being nested and
>>   maybe that'll help..
>> 
>> Search the for "gcc type punning"
>> => wikipedia
>> => link at the bottom
>> 
>> http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/Optimize-Options.html#index-fstrict_002daliasing-542
>> 
>> There is a subtlty there though..we'd have use member_ref on the union.
>> They also give some pointer to what to do "for real". I can follow up, later.
>> 
>> 
>> Disabling unit at a time is also lame.
>> 
>> 
>> - Jay
>> 
>> ----------------------------------------
>>> From: hosking at cs.purdue.edu
>>> Date: Sat, 3 Jul 2010 20:50:11 -0400
>>> To: jay.krell at cornell.edu
>>> CC: m3commit at elegosoft.com
>>> Subject: Re: [M3commit] CVS Update: cm3
>>> 
>>> I added it a long time back only because I saw failures with optimisation turned on. Something to do with the alias analysis (and lack of proper type information) as far as I recall.
>>> 
>>> 
>>> On 3 Jul 2010, at 20:44, Jay K wrote:
>>> 
>>>> 
>>>> Tony, just to be clear..you/I are disturbed by volatile, but it has also, I believe, like always been there.
>>>> It has been gone only very briefly, and its non-use is probably limited for other reasons (how many people are
>>>> using it, on how many platforms?).
>>>> 
>>>> 
>>>> - Jay
>>>> 
>>>> ----------------------------------------
>>>>> From: jay.krell at cornell.edu
>>>>> To: hosking at cs.purdue.edu; jkrell at elego.de
>>>>> CC: m3commit at elegosoft.com
>>>>> Subject: RE: [M3commit] CVS Update: cm3
>>>>> Date: Sun, 4 Jul 2010 00:42:20 +0000
>>>>> 
>>>>> 
>>>>> Not a multiprocessor.
>>>>> Still interested in selective volatile?
>>>>> 
>>>>> 
>>>>> This all bothers me too.
>>>>> I don't want volatile. It makes the optimized code terrible.
>>>>> But I don't want to debug any problem from removing it, beyond compilation failure.
>>>>> 
>>>>> 
>>>>> I can try a few things.
>>>>> This is all wierd. I swear I saw it hang several times.
>>>>> I swear I'm trying to to change "too many" variables at a time. Yes, I know, 2 is too many.
>>>>> 
>>>>> 
>>>>> Once I started getting version stamp mismatch, I resorted to using a cross built cm3.
>>>>> Out of necessity sort of, but that causes more flucuation of variables.
>>>>> 
>>>>> Let me try again with volatile and see if it is solid.
>>>>> Then I'll try with only volatile stores.
>>>>> 
>>>>> I've been trying optimized and unoptimized, and not kept good track of which when.
>>>>> 
>>>>> 
>>>>> - Jay
>>>>> 
>>>>> 
>>>>> ----------------------------------------
>>>>>> From: hosking at cs.purdue.edu
>>>>>> Date: Sat, 3 Jul 2010 20:36:20 -0400
>>>>>> To: jkrell at elego.de
>>>>>> CC: m3commit at elegosoft.com
>>>>>> Subject: Re: [M3commit] CVS Update: cm3
>>>>>> 
>>>>>> I am very disturbed that volatile is needed here. Can we selectively turn it on for thread-critical files like ThreadPThread and see if it fixes the problem. I wonder if the double-checked locking is broken for PPC memory model. Is this on a multi-processor?
>>>>>> 
>>>>>> On 3 Jul 2010, at 12:57, Jay Krell wrote:
>>>>>> 
>>>>>>> CVSROOT: /usr/cvs
>>>>>>> Changes by: jkrell at birch. 10/07/03 12:57:09
>>>>>>> 
>>>>>>> Modified files:
>>>>>>> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c
>>>>>>> 
>>>>>>> Log message:
>>>>>>> restore volatile for powerpc and powerpc64 platforms
>>>>>>> This seems to fix PPC_LINUX hanging.
>>>>>>> This needs further debugging, but I'm not eager.
>>>>>>> This will also affect PPC_DARWIN, PPC64_DARWIN, PPC32_OPENBSD,
>>>>>>> PPC32_NETBSD, PPC32_FREEBSD, etc., but these platforms are little used or
>>>>>>> nonexistant.
>>>>>>> 
>>>>>>> Having volatile like has been the very long standing situation though.
>>>>>>> The result is that the optimizer does basically nothing.
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
>