I think I got a fair way through the precompile stage, mostly just replacing immutable’s with struct’s and moving the {T}'s of func{T}() to func() where{T}, but I’ve gotten a bit stuck on an unrecognized :SSAValue, from the Sugar.jl package / methods.jl / line 159
Any tips for what to do here /where i might find a SSAValue type in julia 1.0?
[Added]: Choice of Core.Compiler.OldSSAVal or Core.Compiler.NewSSAVal ? both have matching fieldnames
Small type discovery/listing code for julia 1.0
z = Symbol.(subtypes(Any));
for x in z
println(x);
sleep(0.1);
end;
Next tricky error is an Syntax: “…” expression outside call in methods.jl: line 444, pointed at a docstring
"""
Rewrite the ast to resolve everything statically
and infers the dependencies of an expression
"""
function rewrite_ast(m, expr)
Add[2]: fixed with ...,
Now in Transpiler.jl package / rewriting.jl line 211, first multiline fix needed
# get the concrete function objects
const fast_ops = getfield.(Base.FastMath, collect(values(Base.FastMath.fast_op)))
const slow_ops = getfield.(Base.FastMath, collect(keys(Base.FastMath.fast_op)))
const fast_op_2_op = Dict(zip(fast_ops, slow_ops))
> MethodError: no method matching length(::Module)
The main road block is porting the Sugar.jl relooper to 1.0.
I had a nice IR pattern matching going for 0.7 (in Sugar/sd/07), but sadly I did it just before the huge Julia IR changes hit 0.7, so it became all obsolete -.-
I’d say the best strategy would be to use IRTools, solve IRTools.jl#3, best by reusing Charlotte.jl relooper, and then port some of the sugar passes to IRTools - which we should be able to drastically simplify.
Alternatively, we could also try to update the pattern matching approach in sd/07 to work with Julia’s new IR - shouldn’t be too hard, just needs some new ways to match the new IR blocks.
Transpiler.jl will need quite a bit of a rewrite as well, but I hope to drastically simplify a few things - and it should mainly just be about Sugar.jl preparing the IR for Transpiler to consume.
Let me know if you seriously consider working on this, I want to sit down at some point and get this working
I have build Sugar working in the package shell, test Sugar rolls through to Unicode[4ec0a83e] and then Errors with UndefVar Error: Test not defined. Tbh a lot of what the code is actually doing is probably going quite over my head, but the breakpoint is slowly advancing (I cheated a little somewhere earlier and defined a GotoNode struct with the expected field)
Currently stuck on @cl_intrinsic SpecialFunctions.erfc(::T) where{T <: AbstractFloat} = ret(T)
TypeError in isdefined: expected symbol, got expression, in Intrinsics.jl line 85
Making Sugar.jl compile on 1.0 won’t help you much, since all the IR transformations it does are invalid on 1.0 because of how 1.0 drastically changed the IR.
Ah that’s a bit of a bugger, but i’m quite thankful for the heads up early, I could’ve spent all week or more tinkering away. They do make for good coding challenges though
Yeah, glad you asked
Porting Charlottes looper to IRTools might actually be not as hard, since it seemed already be written with the design of IRTools in mind… So that would be a tremendous help to get me started!
Unless @sdanisch or someone else has plans to make a significant investment into getting CLArrays’ deps running on 1.x, I’d say it’s not going to make any progress in terms of features (although “trivial” bugs can still be squashed) and will have very limited capabilities on Julia 1.x. Assuming no one pitches in to get the necessary dependencies working again, I see the following being the “future”:
All users: Can write plain OpenCL C kernels and call those manually.
AMD GPU users: Can use HSAArrays.jl once I get things implemented.
Intel GPU users: Can wait until LLVM support is working for Intel GPUs (assuming this happens, I think it will), at which point someone will implement Julia codegen and array packages for them (if no one else steps up, I’ll probably get it started).
I think it’d be really cool if someone does step up and put in the time and effort to rewrite Transpiler for Julia 1.x (or something equivalent that CLArrays can use), as it would be a really useful to have OpenCL support for anything which doesn’t have a working LLVM backend. As always, there are plenty of people willing to assist the brave soul who wants to take that on.
