Is there a way to transform, or even just visit, I...

# compiler

[Caleb B]

Is there a way to transform, or even just visit, IR after all inlining has occurred?

[Youssef Shoaib [MOD]]

FYI, JVM inlining happens on JVM bytecode, not IR, so it wouldn't work in that regard. You can try to use the IR inliner on your own, but I'm not sure how successful that'd be

[Caleb B]

I'm migrating the type of individual parameters specifically, which could share the same type, so I need to make sure I know all variables in the final function that are reassignments of a parameter. It's JVM only for now, so I could also do it if I inject myself into the lowering process. Is there a way to do that?

[Caleb B]

I mean, I guess I could also do that in bytecode, checking for ALOAD x ASTORE y, but I'm worried about cases that are more complicated than that.

[Youssef Shoaib [MOD]]

To be clear, JVM does not inline at the IR level. It inlines into bytecode only, so there are no IR lowerings that'll help here. A JVM Bytecode transformer is likely what you want then.
Depending on how your plugin works, you can simply compile the dependencies with it, and hence the inlined bytecode will have already been transformed. That only works if you can control the dependencies, though.

[Caleb B]

Makes sense, if a bit tragically so. I guess I'll have to do most of my marking in bytecode instead of IR.
Is there any way to trigger a bytecode transformer within the compiler plugin framework instead of requiring users to run a special postprocessing task in Gradle?

[Youssef Shoaib [MOD]]

I couldn't find anything. Thankfully, it's already very normal to have a gradle plugin that applies the compiler plugin in the first place, so you can register your task there

[Caleb B]

I guess so, I just hate how brittle class transformation always is in Gradle. classes.finalizedBy(mytask) my beloathed...

[Caleb B]

Do you happen to know if there's an ASM helper for tracking what's on the stack when a method is called? I can't find anything in the library, but the behavior exists in ClassWriter.

[Caleb B]

Ah, the AnalyzerAdapter does that too. Cool.