Is it possible to throw errors over missed compiler optimizations?

Hi all. I have a naive question: is it possible, and how involved would it be, to somehow write Julia code that throws an error if certain compiler optimizations fail to happen? Like, if you accidentally use globals/type inference fails/loops don’t vectorize/etc. Considering the incredible power of @code_llvm and @code_warntype, in my ignorance I would guess something like

@assert_vectorize for j in 1:(2^14)

or

@assert_concrete_type T function hot_loop(M::Matrix{T}) where{T}

or

@assert_specialize arg function will_fail_if_given_function(arg) 

or

@assert_type_stable function f(...)

should be possible. But honestly I have no idea how much work it would be. I am aware that in the second example you could just include a @assert isconcretetype(T), but hopefully you get the point of the examples.

If a suite of tools like this is conceivably possible, I do think it would be pretty valuable. For one, at least in performance-intensive code it would be nice because I (and I assume everybody) would actually rather something breaks than for it to silently run and not give me the performance I’m expecting.

But also, this kind of issue has been perhaps the primary pain point of bringing new users into the language. Particularly people who do know something about programming with type systems but just aren’t familiar with Julia. They write code that runs and it looks perfectly sensible, but it’s just slow. To be clear, the language is great in the sense that I can then easily explain the problem, suggest using @code_warntype or whatever, and then the new user walks away with a better understanding that will translate to better code in the future. But for people who are more on their own and don’t have a buddy that has gone through it or a sort of intrinsic interest in programming languages to the point where it’s almost a hobby to understand why something is slower than they expected, I’d guess at least some will just walk away with the wrong impression. These tools wouldn’t be ideal for solving this problem I’m describing because it’s a much harsher introduction to heuristic reasoning about the compiler, but at least it would be something to offer the performance fiends who want to experiment and be sure that they’re not just getting slowed down by some fixable gotcha.

Anyways, this is getting long, sorry. I’m curious to hear the community’s thoughts on the question, both about whether a set of general-use tools like this would be possible and how much work it would be. And whether it is a bad idea, I suppose. I’m perfectly willing to try and contribute (starting in, like, a month).