5 ms·

Do you think this exercise has taught you anything that could make fil c itself better?

• pizlonator 5mo ago
  Yeah I really need to have a better fix for how I handle unions. And the fact that having outline calls to methods of value objects is so expensive
  • achierius 5mo ago
    > And the fact that having outline calls to methods of value objects is so expensive Is this tied to unions? Or otherwise, when does this happen? I don't see the connection w/ invisicaps or &c
    • pizlonator 5mo ago
      In Fil-C, currently, all stack allocations that “escape” need to be allocated in the heap. “Escape” is defined very loosely; it currently means: some function other than the one that owns the stack allocation needs a pointer to that allocation. For example even if you could prove that `bar(Value* p)` never stashes p anywhere, the fil-C compiler will currently heap allocate that value anytime bar is called. The one exception is if bar had already been inlined, and so from the FilPizlonator’s perspective there isn’t even a call. This is clearly dumb and fixable. It’s dumb because lots of functions aren’t worth inlining but their body is analyzable. Slow paths are like that. It’s fixable because those slow paths - and lots of code like them - takes ptrs as arguments and then obviously just uses them for loads and stores but doesn’t escape them any further. You’ll sometimes hear me say that Fil-C is nowhere near as optimal as it could be. This is just one example of that