[M3devel] optimizer problems

[Jay K]

I will experiment more.
I don't remember if I tried as much as "exported", which is clearly wrong, but it'd be interesting to see if *some* way can preserve it. Should also be easy to find the code that removes it.
 
 
 
I have more questions..not well formed..not having researched a lot..so have held off..but..like..what is it about our trees? What is it you refer to as the missing type information and the problems with alias analysis? I understand to some extent. But we do actually mostly seem to build reasonable and reasonably typed trees.
Granted, I haven't compared to C trees.
I guess using the various dump option for C trees and our trees would be good.
 
 
 
I think one place we fail is access globals, and indeed accessing structs.
We just offset from them I think, instead of accessing fields.
Is that what you mean??
 
 
For "scalar" locals and globals, our trees seem ok, right?
 
 
 
As I aid, I should just use more of the gcc dump options and compare.
 
 
TYPE T1 = RECORD a,b:INTEGER END;
 
global:T1{3,4};
 
PROCEDURE F1() =
VAR local:T1{1,2};
BEGIN
  local.a := global.b;
  globa.a := local.b;
END;
 
 
typedef struct {ptrdiff_t a,b;}T1;
T1 global = {3,4};
 
void F1()
{
  T1 local = {1,2};
  local.a = global.b;
  global.a = local.b;
}
 
 
I should probably compile each of these and dump their "generic" trees and compare?
And strive to have them match?
 
 
More importantly though is loophole and float.
 
 
TYPE T1 = RECORD a,b:int END;
TYPE T2 = RECORD a,b:float END;
 
 
global:T1{3,4};
 
 
PROCEDURE F1() =
VAR local:T2{0.0,0.0;
BEGIN
  LOOPHOLE(local, T1).a := global.b;
  LOOPHOLE(global, T2).a := local.b;
END;
 
 
typedef struct {int a,b;}T1;
typedef struct {float a,b;}T2;
T1 global = {3,4};
 
 
void F1()
{
  T2 local = {0,0};
  ((T1*)&local)->a = global.b;
  ((T2*)&global)->a = local.b;
}
 
 
stuff like that?
Get those C and Modula-3 trees to match?
 
 
I assume as part of this, if it seems "necessary" to add volatile store/load to all loophole uses,
in order to remove volatile from floats, that is probably an ok compromise.
Even when loophole is acting on non-floats.
Maybe the problem is loophole and structs though. That seems likely.
Ideally loopholing between integers and pointers doesn't require store/load, as it currently doesn't.
 
 
Again, really, though I've removed a lot of volatile, I'm still quite bothered, since I still put it on every floating point use.
 
 
The vrp/fre/pre stuff I think will be more difficult, but maybe I can figure those out.
vrp I just know results in a broken compiler. I haven't looked at it beyond that.
I guess the thing to do is compile some chunk of code, e.g. m3core, with vrp being the only variable, and see what varies, and go from there.
 
 
Given how much optimization does work now, I doubt the effort is very worthwhile on the lingering view I disabled, except, again, for unit at a time and volatile float. We'll see..
 
 
I was doing kind of dumb slow unscientific work before. There are many optimization flags and I wanted to narrow them down more than one at a time, so I'd guess, switch a few on, upgrade, if it worked proceed, if it failed, alter the guess some.
 
 
And there's still Solaris/sparc32 to do similar with..
Should be more automated but my current methods are quite tedious.. :(
 
 
 
 - Jay











________________________________
> From: hosking at cs.purdue.edu
> Date: Fri, 4 Jun 2010 13:56:44 -0400
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] optimizer problems
>
>
>
> Or "external". I assume it is getting dead code eliminated.
>
>
> 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 4 Jun 2010, at 13:06, Jay K wrote:
>
>
> I already tried that.. :(
>
>
> - Jay
>
>
> ----------------------------------------
> From: hosking at cs.purdue.edu
> Date: Fri, 4 Jun 2010 12:37:45 -0400
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] optimizer problems
>
> You should be able to mark it as used.
>
> On 4 Jun 2010, at 12:29, Jay K wrote:
>
>
> Just a note that I have found at least two pieces of code that fail to compile with optimization enabled, even in the release branch.
>
> One is a simple case involving unused nested functions.
> One is a complicated not really understood case.
>
>
> To fix these I have pessimized the optimizer in the release branch but turning off two optimizations.
>
>
> It would be nice to find a better fix for the first.
> Even something sleazy like having the front end report up front to the backend if there are any nested functions in the unit, and only pessimizing such units.
> There is probably also a fix to gcc around preserving nested functions. I thought code in varasm.c was suspicious but couldn't get it to work quickly.
>
>