Core.Compiler removed required methods in 1.5 <
ERROR: LoadError: UndefVarError: just_construct_ssa not defined
when using the package in 1.5.
In 1.6, there's also an issue with Params moved out of Core.Compiler (to make room for AbstractInterpreter.
Just throwing it up here so it will be on the radar.
We've been just_construct_ssa-free for a while and the latest release passes tests on 1.5. I also just removed a last vestige of typed IR in https://github.com/MikeInnes/IRTools.jl/commit/93fa60dd2085fc9646e774f84f5b027ee7c8b611.
A new problem on 1.6 is that the Base IRCode constructor has changed. We only touch Base's IR format when converting IR to CodeInfo. The options are to fix that constructor, assuming Base IR hasn't changed too much, or to just rewrite that conversion ourselves, which is a little harder but more of a long-term fix.
A while back we wrote our own CodeInfo -> IR conversion and that's proved pretty robust (we haven't had to touch it since).
Looks like I didn't update my dependencies before precompiling - apologies for the non-issue.
If I'm understanding correctly on the second point, the issue is now going back from IR -> CodeInfo. I'm guessing this functionality is used in evalir and func? So that you can can lower to the IRTools IR, then return to CodeInfo and release to the normal pipeline.
I'm in no position to say, but the latter option seems optimal - you basically de-couple IRTools from Base changes permanently.
Is there a fix/workaround for Params not defined in julia master?
It'd be good to get Flux working on julia master given 1.5 is now released.
One reason is so that invalidations can be investigated with the new tooling
@ianshmean do you mean Zygote? I didn’t think Flux had any dependency else through Zygote?
Indeed. But ultimately it blocks Flux, so I thought I'd refer to that given it's the main package in the org.
Sure - generically there’s two directions here. One is to make Zygote compatible with > 1.6 - that means we need to fix these issues.
The second direction is to provide a backend for Flux which uses the new AD system in development. I’m guessing that new AD will become available as 1.6 releases.
In the first case, I’m not sure I can be of much help. I’m not a contributor here, and I don’t have the bandwidth currently to dig in.
I was unaware that Flux was undergoing a big change like that. Is there a particular issue to track?
It’s not Flux in particular. It’s a part of new compiler infrastructure. You can follow the work here: https://github.com/Keno/Compiler3.jl
Ok. So if I understand correctly, you're saying that that is due to be merged before 1.6, thus fixing Flux will probably wait until after that merges?
I don't have information about what's going on here. This is just my pure speculation. But it is known that new AD is coming (and Keno is working on it, as a part of this work which I mentioned above). And I'm guessing that Flux will have some effort associated with using the new AD.
Regardless, it would be good to fix these issues anyways so I totally agree with you.