handle multiple optional operands

[jumerckx]

for example openacc.enter_data:

function enter_data(ifCond=nothing::Union{Nothing, Value}; asyncOperand=nothing::Union{Nothing, Value}, waitDevnum=nothing::Union{Nothing, Value}, waitOperands::Vector{Value}, copyinOperands::Vector{Value}, createOperands::Vector{Value}, createZeroOperands::Vector{Value}, attachOperands::Vector{Value}, async=nothing, wait=nothing, location=Location())
    results = IR.Type[]
    operands = Value[waitOperands..., copyinOperands..., createOperands..., createZeroOperands..., attachOperands..., ]
    owned_regions = Region[]
    successors = Block[]
    attributes = NamedAttribute[]
    !isnothing(ifCond) && push!(operands, ifCond)
    !isnothing(asyncOperand) && push!(operands, asyncOperand)
    !isnothing(waitDevnum) && push!(operands, waitDevnum)
    push!(attributes, operandsegmentsizes([isnothing(ifCond) ? 0 : 1, isnothing(asyncOperand) ? 0 : 1, isnothing(waitDevnum) ? 0 : 1, length(waitOperands), length(copyinOperands), length(createOperands), length(createZeroOperands), length(attachOperands), ]))
    !isnothing(async) && push!(attributes, namedattribute("async", async))
    !isnothing(wait) && push!(attributes, namedattribute("wait", wait))
    
    IR.create_operation(
        "acc.enter_data", location;
        operands, owned_regions, successors, attributes,
        results=results,
        result_inference=false
    )
end

There's a trailing comma in the list now but that should be no problem.

[mofeing]

Do you mind running the formatter? That way we can check out more easily if the bug is solved.

[jumerckx]

I ran the formatter using

format(".", JuliaFormatter.BlueStyle())

and the ternary operators haven't been replaced by if-else statements. Not sure whether that's good or bad.

[mofeing]

That's okay: it's how we have it right now.

[jumerckx]

I've now pushed dialects for all versions except 18 because I'm not sure how to actually do that.
There are also some small changes to the libMLIR_h.jls for some reason. I've added them to this pr but can revert that commit if wanted.

[mofeing]

Are these renames intentional?

[jumerckx]

Yes, that change was introduced here #74 to fix e.g.

MLIR.jl/src/Dialects/18/LLVMIR.jl

Line 366 in b355c7a

!isnothing(results) && push!(results, results)

It looks like the dialects for LLVM18 weren't generated using the newest generator.

[mofeing]

Ah yeah, in that case wouldn't be better to prioritize a clean interface? (i.e. to use _results as the variable inside and results as the kwarg).

[jumerckx]

This should be the case now.

[mofeing]

Actually with just the jl_generator.cc would be ok, since then I can upload it to Yggdrasil and regenerate them correctly.

[jumerckx]

Actually with just the jl_generator.cc would be ok

you mean to not yet include the generated dialects for LLVM18? or also get rid of the other versions in this PR?

[mofeing]

Exactly, we can generate it with bindings/make.jl once it's up in Yggdrasil.

[jumerckx]

Exactly, we can generate it with bindings/make.jl once it's up in Yggdrasil.

For now I've only included the generated files for LLVM14 to be able to inspect, I can remove those before merging.

EDIT: nvm, I added the other versions as well to check CI.

[jumerckx]

Green!

[mofeing]

Great! Thanks @jumerckx!