inlining and recursive processing

[ninegua]

I feel that the code in get_ir_of_code is becoming a re-implementation of Pipeline in compiler.py.

I believe we had this function because we want the result IR to be inlined. There are two places where we need inlining:

1. before type inference. The primary reason for doing this is that the code to be inlined comes untyped, and will get type inference for free once inlined.
2. after type inference. The primary reason for doing this is when we need type information before we can be sure which code to inline.

So instead of doing recursive processing on demand, which is similar to invoking the most of the pipeline on a function up to a certain point (like rewrite, or array analysis, or even after parfor), I would suggest we add a post-inference inline pass instead, which is what replace_parallel_functions currently does. This should cut down on the complexity of having to do recursive processing, and simplify things quite a bit. (I actually had already implemented it in a separate branch, which works out great)

Now this is getting awfully similar to what rewrite pass is about, which unfortunately only gives access to things on a per-block basis. But I think a solution to merge inline with rewrite can come in the future.

What do you think? @ehsantn @DrTodd13

[ehsantn]

I think having a separate typed inline pass can be cleaner, but handling all the use cases of get_ir_of_code and compile_to_numba_ir can be challenging since fine-grained control might be required. For example, HPAT replaces some functions based on conditions such as input values, and this logic can't be passed as parameter to a separate pass easily. We can have a meeting to discuss the specifics.