🚀 go-pugleaf

brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
>What I'd love to see is a way to turn on optimizer debugging output for
>a section of code. The optimizer would print out everything that it
>looks for while optimizing, what it finds, and what it's not sure about.

It's been done, somewhat, for the case of dependence-driven
transformations -- get info on PTOOL at Rice.  I am told that in
general (i.e., their experience has been) you really *don't* want
"everything" that the optimizer looks for, finds, or is unsure about.
If you think about how large some optimizing compilers get while
optimizing, you can see why you might not want to know everything.

The last time I paid much attention to the design of the user
interface on this (years ago), it was proposed that it take the form:

  1) compiler performs transformations;

  2) user is presented with transformed code;

  3) user queries compiler as to why certain transformations
     were not performed;

  4) compiler answers, and user either says "oh yeah, you're right",
     or supplies assertions, or says "do it anyway" (sometimes chaotic
     convergence is ok, for example).

Ideally, the feedback would be remembered in the form of
pragmas/assertions automatically inserted into the source code.  I
believe that the reason you see this done for dependence analysis, but
not for more ordinary optimizations, is that the pay-offs are so much
larger (vectorize, or not?  parallelize, or not?), and that the cost
of the machine (e.g., Cray) time saved often is greater than the cost
of the time spent by humans to do the machine-aided transformations.

This is less often the case for more ordinary transformations on more
ordinary computers, especially as cycles get cheaper and cheaper.  Of
course, we could always strive for ultimate program speed as a sort of
a sport -- we do something like that for chess already.

David Chase
Sun Microsystems