Big update to prettier-extension-monkeyc

I don't know if the bug is new. It could be there forever, I didn't have the try/catch there before, just added it a few minutes before I reported the problem. What I was saying is that I was expecting the "can't be inlined" warning I was familiar with and instead I saw this new "phenomenon".

import Toybox.Lang;
import Toybox.Activity;
import Toybox.Time;

class Test {
    protected var mResult2 as String or Numeric or Null = null;

    public function compute() as Lang.Numeric or Time.Duration or Lang.String or Null {
        var extHr = computeExtHR();
        if (mResult2 != null) {
            extHr += " " + mResult2;
        }
        return extHr;
    }

    typedef AlphaNumeric as String or Number;

    (:inline)
    hidden function computeExtHR() as AlphaNumeric {
        var result;
        var result2 = mResult2;
        mResult2 = result2;
        return result;
    }
}

flocsy

Thanks - that made it easy to debug. As I mentioned, I use some heuristics to break accesses into groups to try to find some profitable variables to extract, even if I can't do all of them. But the groups were limited to basic-block boundaries in the control flow graph (nothing to do with { } in the source - just wherever a branch may occur). And in your example, the first block has a read, then a write, then another read, and the second block has a read. So the choices were to do the first three accesses, to do the last access, or to do all 4. And none of those is profitable.

So I just did a post-processing step that breaks a block any time it finds a read and a write of the same variable. That fixed your example, and over all of my test projects PRE now does much better. But looking at the before/after optimized code, Im seeing some a few places where it was doing better before the change. So I'm going to debug those... but overall this looks pretty good.

Glad this could help.

I am seeing another "issue". This is not an error more like "wishful thinking" from my side. And the "wish" is that if I do some "manual" optimizations then the optimizer should produce code at least as good as it would without my manual optimizations. I'll give you an example, but probably there are many more types it could be applied to.

Sometimes you have a function f, that uses some literals and it calls another function g that is inlined and g also uses some literals. So my manual optimization would be to pass the variable I created to replace the literal from f to g.

    public function f() as Void {
        some code where the following literals are used:
        1 - once
        2 - twice
        3 - three times
        4 - 4 times
        7 - once
        g();
    }

    (:memory16K, :inline)
    hidden function g() as Void {}
    (:memory23K, :inline)
    hidden function g() as Void {
        some code where the following literals are used:
        1 - once
        2 - once
        3 - twice
        4 - 3 times
        7 - 3+ times
    }

The numbers (how many times the literals are used) are not really important, I think you get the idea. If any Number would be used at least 3 times in any of the functions I would probably create a variable like: var three = 3; and use that in the same function. If I already created a variable that is useful in g then maybe I would notice and pass it (no matter how many times it's used in g), etc...

To make things a bit more interesting g is doing something else (it's usually but not always: nothing) for some devices.

Now the thing is that if I would only care about either one of the 4 combinations:

memory16K, no-optimizer vs memory32K, no-optimizer vs memory16K, optimizer vs memory32K, optimizer

then I can test each variation and do what's best for that combination. However I care for at least all the different devices with the optimizer (for obvious reasons, but to give some more context why even that is not always trivial, you might think that it really only matters for the devices with the least amount of memory, but its not always good enough: until about a month ago I did most of my optimizations in order to be able to squeeze as much functionality to devices with 16K, and on the way I was also gaining some free space for 32K devices, but then I reached a point where even the 32K devices started to have problems with the memory, so I added a new split: memory16K, memory16Kplus, memory32K, memory32Kplus)

And to make things even "worse": I like to be able to debug as much as possible without the optimizer so I'd rather not pass these literal variables because that makes the non-optimized version worse sometimes (when there are less than 3 usages in either f or g or both and only have three or four usages in f+g combined).

So my wish (and I know it's a big one, but hopefully PRE will be able to help in some cases) is to be able to keep the code "manually optimized" for the compiler without prettier-optimizer, but that prettier-optimizer would be clever enough to do these "automatic optimizations".

In my above example, 7 is something that is better not to pass without prettier but better to pass with.
I'll also add, that in my case I already have var seven = 7; in g(), so maybe that makes it a bit less obvious for the optimizer to spot it. I didn't try it how it would score if I just had the literal 7-s.

v2.0.39 is out.

This includes a pretty much fully rewritten optimizer, using a type analysis pass to enable better optimizations.

I've put a lot of effort into verifying that this doesn't break anything, but it is a big change. If anything breaks, please report it (here, or in the GitHub issues), with as much detail as you can.

Most of the optimizer changes are listed here.

here's also a constant related new bug:

const HR_ZONES_MOCK = null as Array<Number>;
(:inline)
hidden function setHeartRateZonesMock() as Void {
  if (MOCK && HR_ZONES_MOCK != null && mHeartRateZones == null) {
    setHeartRateZones(HR_ZONES_MOCK);
  }
}

is being transformed into:

Here's something that got "un-optimized":

I manually optimized my code not to include the same 1 character string twice:

var a = "-";
var b = a;

and the optimizer undid it:
var a = "-";
var b = "-";

When I compare the above 2 variants (without the optimizer) then then the 2nd uses 3 bytes more code. 

and here's the reason why f6 became so much worse: some juggling with annotations + constant got to the wrong conclusion:

my code:

(:debug, :memory32K) const LOG = false;

(:debug, :inline)
function log(msg as String) as Void {
    if (LOG) {
        logRelease(msg);
    }
}
function logRelease(msg as String) as Void {
    System.println(Time.now().value() + " " + msg);
}

log("sAN: " + (name == null ? "null" : name) + ", " + (isNewName ? 1 : 0) + ", p:" + mPrevAntId + ", a:" + antId);

2.0.38 correctly removed this whole block (the call to log() INCLUDING the calculation of it's parameter)

and 2.0.39 partially included it:

      {
        var msg =
          "sAN: " +
          (name == null ? "null" : name) +
          ", " +
          (isNewName ? pre_1 : pre_0) +
          ", p:" +
          mPrevAntId +
          ", a:" +
          antId;
      }

Again: it created the variable that it doesn't use later. log() is not called, so It wasn't obvious to see the difference in functionality, but it included a huge chuck of "noop" code.

flocsy said:

This is not an error more like "wishful thinking" from my side

This is something that is almost working in the next release. Yet again, it depended on type propagation, so hasn't been possible until now; and I decided to release what I had, rather than keep adding more features (I've already added more features than I had intended for the initial type-propagation release; but every time I add a feature, I see how much better it could be if I added just one more thing...).