Update to v0.3.0 of llir/llvm (released yesterday).

[mewmew]

Note, the v0.3.0 release had a few changes to the API. The most
intrusive one may be to use value.Value in all places where
operands of instructions are used. This has both pros and cons,
where the cons include less exact types used for instruction and
terminator operands. The benefit is that this change enable a
unified and quite powerful use-tracking API, as further outlined
in llir/llvm#50, llir/llvm#122 and llir/irutil#1.

[mewmew]

Hi @andybalholm,

Hope you've had a great winter holidays thus far. I went up to the northern part of Sweden to meet my cousins and go skiing together.

Just wanted to get you and leaven up to speed with the latest llir/llvm release :) As detailed in the commit message of this PR, there was an API update which effects a lot of uses of llir/llvm, hopefully it will have an overall positive rather than negative effect on uses cases, but the API design choice was a trade-off that we think will pave way for a quite powerful use-tracking and operand modification API in v0.4.0. I'd be curious to hear what your thoughts are on the change if you'd like to share.

Wish you all the best and a great adventures in 2020! :)

Cheers,
Robin

[andybalholm]

A use-tracking API sure sounds nice. Maybe it would be possible to eliminate all the underscore assignments in the generated code then.

[andybalholm]

By the way, it's pretty nice when my dependencies send me pull requests to fix their API breakage. :-)

[mewmew]

A use-tracking API sure sounds nice. Maybe it would be possible to eliminate all the underscore assignments in the generated code then.

Yeah, that's definitely the intention! I'd miss the landscape art of Leaven though with _ as ground and , as trees :)

	_, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _ = v0, v1, cmp13, tobool14, or_cond15, r_addr_017, l_addr_016, incdec_ptr, incdec_ptr4, v2, v3, cmp, tobool, or_cond, _lcssa12, _lcssa, conv5, conv6, sub