Splitting builtin support between the IR and the backend

[chuggafan]

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]

yeah it sounds good...

[chuggafan]

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]

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]

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]

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]

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