Should there be invalidation edges to inactive_type from generated functions?

[danielwe]

A lot/most of the usage of inactive_type is in the generator of generated functions, often via generated_const or active_reg_nothrow. Since generators are frozen in the world age/precompilation workflow where they were defined, adding methods to inactive_type from other packages/extensions has very limited effect. Even guess_activity is blind to inactive_type methods defined outside Enzyme because it uses active_reg_nothrow, not to mention everything in jitrules.jl. It's also a problem for certain use cases for #1852, where it's often desirable to use guaranteed_const rather than guaranteed_const_nongen for performance reasons.

I understand from source code comments that it's possible to explicitly add invalidation edges to generated functions. Should this be considered for generators that rely directly or indirectly on inactive_type?

[danielwe]

It's also a problem for certain use cases for #1852, where it's often desirable to use guaranteed_const rather than guaranteed_const_nongen for performance reasons.

Actually, more than performance, the main motivation for #1852 is for custom rules, and such rules sometimes fail to compile when recursive_map uses guaranteed_const_nongen instead of guaranteed_const. (I get Enzyme compilation failed due to an internal error.) I suppose I could open a separate issue for that. Either way, it's important to at least clarify in the documentation what you will and will not accomplish by extending inactive_type, but ideally also increase consistency between inactive_type and actual behavior.

[wsmoses]

yes absolutely there should be!

[danielwe]

Actually, would invalidation edges help, or would the generator remain stuck in its world age and simply reproduce the same methodinstances over again? This goes way too deep into compiler weeds for me...