[M3devel] aliases/optimization

[Jay K]

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