[refactor] Remove FrontendContext and the global context

[k-ye]

Since Program is global, and it also provides current_kernel, I think current_ast_builder() can be implemented via current_program -> current_kernel -> ir_builder. This PR inlines FrontendContext' members directly into Kernel, and removes the global FrontendContext context.

@yuanming-hu i saw that FrontendContext was introduced for quite some time now (Feb 2019). Could you take a look and confirm if this change makes sense? I think current_ast_builder() is used when constructing the AST, during which time program.current_kernel is set:

taichi/taichi/program/kernel.cpp

Lines 22 to 26 in d19ccd9

	program.current_kernel = this;
	program.start_function_definition(this);
	func();
	program.end_function_definition();
	program.current_kernel = nullptr;

Related issue = #689

[Click here for the format server]

[yuanming-hu]

So here are my thoughts (not sure it makes sense though)

• We are trying to decouple the frontend (taichi lang) from the middle end (CHI)
• To decouple we may want to construct a frontend AST without a Program or Kernel. Then we use lower_ast and pass the lowered CHI IR to a Kernel.
• This means having a FrontendContext for AST creation might be helpful?
• get_current_program() and Program::current_kernel should actually be removed in the future. These are global states that we should avoid. (Sorry about my bad initial design...) In fact, I already find Program::current_kernel painful since I'm adding parallel compilation. Then multiple threads may fight for this variable.

WDYT?

[k-ye]

Can't agree more..

To decouple we may want to construct a frontend AST without a Program or Kernel. Then we use lower_ast and pass the lowered CHI IR to a Kernel.

Ah I see. Currently I see that each Kernel resets FrontendContext, and thought it's coupled.

This means having a FrontendContext for AST creation might be helpful?

Yeah, but I'd still hope FrontendContext not to be global, especially considering that parallel compilation implies parallel AST building? Do you have an idea that, if FrontendContext is decoupled from Kernel, who would own it? Maybe there would be a collection of FrontendContext inside Program or something?

[yuanming-hu]

Yeah, but I'd still hope FrontendContext not to be global, especially considering that parallel compilation implies parallel AST building? Do you have an idea that, if FrontendContext is decoupled from Kernel, who would own it? Maybe there would be a collection of FrontendContext inside Program or something?

Right, we should not make FrontendContext global. In fact, I think it should be named TaichiASTBuilder (which combines the current FrontendContext and IRBuilder), and the method who is creating the AST owns it. After the AST is built and fetched, the builder should be safe to delete. It should be similar to the design of llvm::IRBuilder.

[k-ye]

and the method who is creating the AST owns it.

Right, the problem is that many IRs are implicitly using current_ast_builder, which is global.. (This is also exported to python for some Stmts, see

taichi/taichi/python/export_lang.cpp

Lines 256 to 258 in d19ccd9

	m.def("create_internal_func_stmt", [&](const std::string &msg) {
	current_ast_builder().insert(std::make_unique<InternalFuncStmt>(msg));
	});

)

I guess there would have to be a major refactor around how we build AST... i.e. instead of IR stmts know where to find that builder, we inverse the dependency and put the IR stmt into a builder?

[yuanming-hu]

we inverse the dependency and put the IR stmt into a builder?

Now sure if I correctly get your point, but here is a potential solution: simply make create_internal_func_stmt a member of TaichiASTBuilder, so that we can do something like
ast_builder.create_internal_func_stmt(...). Then this would be the ast_builder we need. (Maybe you mean the same thing...)

[k-ye]

Ha yeah, that is what I meant... Let me close this PR