search

LADSoft / OrangeC

OrangeC Compiler And Tool Chain
http://ladsoft.tripod.com/orange_c_compiler.html
Other
291 stars 39 forks source link

Splitting builtin support between the IR and the backend #577

Open chuggafan opened 3 years ago

chuggafan commented 3 years ago

As per the title, I think it would be paramount to split the builtins support between the backend and the middleend, the reason that I propose this is fourfold:

  1. By splitting the support to the middleend initially, we will be able to optimize the register usage for individual uses, preventing the expensive calling convention setups for fastcall.
  2. Depending on the architecture, if there is no instruction-level support, we could theoretically insert an IR-level block for what we want to do and have the optimizer work with that.
  3. Some builtins are platform specific, if we mark those builtins in the middle-end we can spit them out and say "Not supported for this platform" and error out because of it
  4. Continuing with 4, when there IS a platform specific builtin, we can optimize how we get into a valid state for it and execute the individual instruction, allowing us to support sse intrinsics without having expensive move-arounds (related to #304 in a way).

This is a rather hefty issue so I definitely think this belongs sometime after milestone 4, possibly after milestone 5.

LADSoft commented 3 years ago

yeah it sounds good...

chuggafan commented 3 years ago

We could even add an IR stage for the frontend now that I think about it, because some builtins are special for each stage such as the template and constexpr ones HAVE to be in the frontend, whilst the middle-end can work with the "generic" IR stuff and transform the IR builtins into either platform-independent code or platform-specific code, and the backend can take the platform-specific builtins and spit out a lowered version.

Makes things easy if we place it all in one spot, I think.

LADSoft commented 3 years ago

yeah, I was thinking today of adding an attribute [[occ::intrinsic]] to mark intrinsic functions and classes in the front end. But that is mostly for processing things that can't easily or efficiently done with templates... I will probably rehash the two builtin templates that way before long. But still an 'intrinsic' flag could be used to mark that something special must be done when working with a prototype...

chuggafan commented 3 years ago

I don't think an [[occ::intrinsic]] is needed... maybe our current system technically works well? It could probably do with a bit more special casing... thinking about it more should probably be in our interest.

LADSoft commented 3 years ago

when we talk about the middle and backend, it seems like we are mostly talking about function-style builtins. The front end can have template and class builtins as well... so maybe if we do something simple like pass function calls out of the front end in a more compact format, the middle layer can do one of three things with it before doing optimizations. Either it could be streamed in to the intermediate code the way the front end does it now, it could be replaced with some sequence of intermediate code instructions in the middle layer, or it could be passed on to the backend with some minor changes.

chuggafan commented 3 years ago

Yep, sounds about right for what I think should happen.