Choose target ISA in @code_llvm and @code_native

[giordano]

@vchuravy mentioned on slack that it should be possible to teach @code_llvm and @code_native to generate code for a different ISA (but within same architecture) than the target chosen at startup with -C (native by default), with the only caveat that it'd work only for ISAs that are equal to or smaller than the current one.

A nice use case for this would be to able to choose the target in Compiler Explorer, whose julia backend at the moment only generates code for whatever is the native CPU currently being used.

It'd be nice to have pointers of where one would need to look at, in case they were interested in tackling the issue 🙂

[gbaraldi]

I'm not even sure that the ISAs need to be smaller, we should never execute this code. In essence one would need to pass the features to the LLVM module we codegen into.

[giordano]

Oh, that'd be lovely as we wouldn't depend on the current host, that was a limitation mentioned by @vchuravy on slack.

[vchuravy]

That limitation only applies to -C

[giordano]

Ah, I got mixed up about it then!

[vchuravy]

It'd be nice to have pointers of where one would need to look at, in case they were interested in tackling the issue

So code_native/code_llvm use jl_get_llvmf_defn which takes in CodegenParams.

In NewPM PM{jl_ExecutionEngine->cloneTargetMachine(), getOptLevel(jl_options.opt_level)}; we setup a new passmanager based on the global TargetMachine.

julia/src/jitlayers.cpp

Line 2213 in d384a36

getTargetCPU(),

[giordano]

Thanks! Just to check if I understood correctly, one strategy to accomplish this is to add a field to jl_cgparams_t and CodegenParams for the target, which by default would represent the current target, but could optionally be a different ISA, and that'd be used in jl_get_llvmf_defn_impl to create a passmanager for the desired target (handling error cases)?

[vchuravy]

Yeah that's what I would try.

[giordano]

Thanks! I added the "good fist issue" label, sounds like a fun task for someone who wants to get started with the compiler 🙂

[vtjnash]

Only for dump_module=true though. With that flag, we can print code for pretty much any combination of compiler options, pipelines, params, CPUs and target architectures. With dump_module=false though, we can strictly only print (dis)assembly for the native machine with all of the vanilla options.

[hackingwave]

Hey team @gbaraldi @giordano @vtjnash @vtjnash .I am beginner to open source.I want to take this issue .Can you please guide me,may with some doc for above issue.

[gbaraldi]

So first thing I would do is familiarize myself with the chain from code_llvm to jl_get_llvmf_defn_impl and understand how these functions work, because it's those that you will be modifying

[hackingwave]

Ohk sure @gbaraldi ,
I will go through code_llvm to jl_get_llvmf_defn_impl to gain a thorough understanding.

Thankyou.