compiler: remove ir package

[aykevl]

This package was long making the design of the compiler more complicated than it needs to be. Previously this package implemented several optimization passes, but those passes have since moved to work directly with LLVM IR instead of Go SSA. The only remaining pass is the SimpleDCE pass.

This commit removes the *ir.Function type that permeated the whole compiler and instead switches to use *ssa.Function directly. The SimpleDCE pass is kept but is far less tightly coupled to the rest of the compiler so that it can easily be removed once the switch to building and caching packages individually happens.

---

For two previous attempts at this change, see #1008 and #466. This PR is different in that it only refactors but does not remove the SimpleDCE pass. That avoids the slowdown in the previous two PRs, it is purely a refactor. This PR does change the produced binaries and there are even some size changes but they are rare and look random (sometimes 16 bytes more, sometimes 16 bytes less).

[deadprogram]

I saw that the ItsyBitsy-M4 tests had failed TinyHCI. I retried the HCI a few times, and then tried verifying manually from previous version, which passed:

$ make test-itsybitsy-m4 
tinygo flash -size short -target=itsybitsy-m4 -port=/dev/itsybitsy_m4 ./itsybitsy-m4/
   code    data     bss |   flash     ram
  13172      44    6360 |   13216    6404
Running tests...
./build/testrunner /dev/itsybitsy_m4 115200 5

- digitalReadVoltage = ***pass***
- digitalReadGround = ***pass***
- digitalWriteOn = ***pass***
- digitalWriteOff = ***pass***
- analogReadVoltage = ***pass***
- analogReadGround = ***pass***
- analogReadHalfVoltage = ***pass***
- i2cConnectionNoPower = ***pass***
- i2cConnectionPower = ***pass***

### Tests complete.

Seems like this commit somehow broke I2C on the ItsyBitsy-M4 board.

[aykevl]

Well, that's unexpected. I did not expect any behavioral changes (especially since all regular tests pass). I'll investigate the issue.

[aykevl]

Somehow it appears the order of functions is relevant 🤔 When I force declare them all at the beginning, the following binary becomes identical before and after this PR:

tinygo build -o test.hex -target=itsybitsy-m4 -size=short ./examples/mpu6050; and md5sum test.hex

patch:

diff --git a/compiler/compiler.go b/compiler/compiler.go
index 745d2ad2..8c25d874 100644
--- a/compiler/compiler.go
+++ b/compiler/compiler.go
@@ -255,7 +255,10 @@ func CompileProgram(pkgName string, lprogram *loader.Program, machine llvm.Targe
 
        // Predeclare the runtime.alloc function, which is used by the wordpack
        // functionality.
-       c.getFunction(c.program.ImportedPackage("runtime").Members["alloc"].(*ssa.Function))
+       //c.getFunction(c.program.ImportedPackage("runtime").Members["alloc"].(*ssa.Function))
+       for _, f := range functions {
+             c.getFunction(f)
+       }
 
        // Add definitions to declarations.
        var initFuncs []llvm.Value

But I'd like to know why this is relevant.

[aykevl]

I can reproduce this on a PyBoard with the mpu6050 driver example.

[aykevl]

Actually, I can't. It doesn't work before this commit either. When I run this (with a change to delay 3 seconds at startup to get the first printed messages):

tinygo flash -target=pybadge ./examples/mpu6050

I get output like this:

connected: false
0 0 0
0 0 0
0 0 0
-316406 29052 987060
-316406 24169 995605
-314697 26855 993652

That's with this PR, with the commit right before this PR (f159429), and on the release branch (and of course without the temporary patch above).

@deadprogram can you maybe test with a PyBadge, whether you can reproduce this behavior? There may be a different/bigger problem here.

[deadprogram]

@aykevl tested with PyBadge and MPU6050 and it worked exactly as expected with both the latest dev as well as with this branch. No changes to the MPU6050 test program from drivers repo needed.

[deadprogram]

The following change removes the TinyHCI error: tinygo-org/tinyhci@27b25be

Was using a pointer now just using type. That may or may not actually be significant?

[deadprogram]

Actually, no. It was just that I had plugged in the board. Appears that the first time it worked, but did not after a soft reset.

[deadprogram]

I really do not think my m4 adventures are related to this PR, just happened to show up around same time.

[aykevl]

So, does that mean we can ignore the test failure?

[deadprogram]

So, does that mean we can ignore the test failure?

Yes.

[deadprogram]

@niaow this PR is now ready for review.

[niaow]

This looks much better

[aykevl]

@niaow thank you for taking a look!