[M3devel] aliases/optimization

[Jay K]

Further research suggests this is frontend behavior, not backend. Oops my mistake.
I read the C compiler documentation and forget about that division.


Though I haven't tried this, it appears maybe a "lang hook" get_alias_set that returns 0 might be an easy win pessimistic win.
Perhaps, again, only in unsafe modules and/or modules that use loophole (yes, I realize loophole implies unsafe).


It's not clear to me yet what the default alias analysis is.
-1 seems to mean "the default"
and 0 seems to mean "pessimisic"

Oh I didn't realize, we have:

alias_set_type
m3_get_alias_set (tree ARG_UNUSED (t))
{
  return 0;
}

which I'm pretty sure means pessimistic.


 - Jay

----------------------------------------
> Subject: Re: aliases/optimization
> From: hosking at cs.purdue.edu
> Date: Sun, 4 Jul 2010 10:47:03 -0400
> CC: m3devel at elegosoft.com
> To: jay.krell at cornell.edu
>
> Yes, that's right!
>
> On 3 Jul 2010, at 21:16, Jay K wrote:
>
> >
> > 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.
> >>>>>
> >>>>
> >>>
> >>
> >
>