How badly does the function pointer technique effect interprocedural optimization? Since LLVM would know the exact control flow it should be able to do the optimisations anyway?
That match(int) technique seems naïve. How would you handle the function arguments/application. The size of the function would also, presumably, large enough to be either very bad for one's icache or requiring more optimisation, which on the assumption that my previous paragraph is correct would make this a wasted effort?
> The way GHC currently compiles is to first reduce Haskell to a Core language, which is a minimal subset of Haskell, in some sense.
GHC Core is not a subset of Haskell, it's just a simplification of it. The same thing but explained with fewer words (constructors).
That being said, we completely agree that Spineless Tagless G-Machine is full of badassery. Just imagine being able to reduce any Haskell app to, like, 8 different instructions. Something about that fascinates me, even though I'm not quite sure what it is.
> Just imagine being able to reduce any Haskell app to, like, 8 different instructions.
It's a universal property of all programming languages that they can be reduced to a language with just one instruction, so it isn't a surprising result.
The only type information I can think of is invariants from type definitions and their use (e.g. this ADT contains an Integer that is never less than 5). This information can be used to (say) constant fold branches. This information would have to be reinferred by the optimiser. However, I don't think this would do anything because AFAIK LLVM can already get infer this.
This could give a speed boost: LLVM has llvm.assume with which one can annotate IR with, using this would mean that the optimizer doesn't have to infer this (and therefore save time).
As a person starting to learn Haskell I only understood the steps to Machine code and that you want to cut down the intermediate steps (to C-- step) and go directly to LLVM. If it makes Haskell better you have my best wishes. Haskell is one of those languages that gets less attention that it deserves.
14 comments
[ 2.1 ms ] story [ 66.4 ms ] threadThat match(int) technique seems naïve. How would you handle the function arguments/application. The size of the function would also, presumably, large enough to be either very bad for one's icache or requiring more optimisation, which on the assumption that my previous paragraph is correct would make this a wasted effort?
Has this been profiled at all?
I wonder what it would take to add a wiki to lambda-the-ultimate.
GHC Core is not a subset of Haskell, it's just a simplification of it. The same thing but explained with fewer words (constructors).
That being said, we completely agree that Spineless Tagless G-Machine is full of badassery. Just imagine being able to reduce any Haskell app to, like, 8 different instructions. Something about that fascinates me, even though I'm not quite sure what it is.
It's a universal property of all programming languages that they can be reduced to a language with just one instruction, so it isn't a surprising result.
[1] Indeed it defines the operational semantics
What semantic information?
This could give a speed boost: LLVM has llvm.assume with which one can annotate IR with, using this would mean that the optimizer doesn't have to infer this (and therefore save time).