What are the plans for `IrIntrinsicExtension` on other platf kotlinlang #compiler

on other platforms - maybe an issue tracking it? Curious since I would like to implement an intrinsic, but information on this is sparse. It's also kind of disappointing that it has to be done in a platform-specific way, but understandable. Or more generally - is there any other way, current or planned, to implement an intrinsic for a function after inlining (in order to preserve the reified type)?

@sandwwraith Since I discovered this from your change; any chance you know what the plans in the compiler are for this sort of thing? I'm noticing that other plugin authors - such as here + here in Zipline - are simply replacing

IrCall

, which unfortunately seems kind of limiting.

sandwwraith

04/04/2023, 2:45 PM

Currently there's no such plans to introduce intrinsics for other platforms; as you can see, intrinsics on JVM are forced to emit bytecode, therefore they remain highly platform-specific. I'd recommend to take approach of a regular compiler plugin and manipulate IR tree, unless you absolutely have to see the result of an inlining.

damian

04/04/2023, 10:06 PM

Thanks! That's too bad - it leaves a bit of a wart on APIs (like the one I linked above) that prevents adding additional abstractions over function implementations generated through that kind of IR replacement. For example if I wanted to intrinsify

fun <T> generateSomeIntrospection()

, I couldn't also build upon that in a

inline fun <reified T> ServiceProvider.get(): T

in upstream library code that could itself call

generateSomeIntrospection<T>()

without also intrisifying

get

. Such a feature could really open up some doors for plugin authors, I think. Do you think it's worth filing an FR in YouTrack for it?

25 Views

#compiler Join Slack