<div dir="ltr">Hrmm. In C/C++ I can tell individual functions to turn on additional ISA feature sets with compiler-specific <span style="color:rgb(51,51,51);font-family:monospace;font-size:11.7px;text-align:justify;background-color:rgb(226,226,226)">__attribute__((target("avx2")))</span> tricks. This avoids complains from the compiler when I call builtins that aren't available at my current compilation feature level. Perhaps pragmas for the codegen along those lines is what we'd ultimately need? Alternately, if we simply distinguish between what the ghc codegen produces with one set of options and what we're allowed to ask for explicitly with another then user-land tricks like I employ would remain sound.<div><br></div><div>-Edward</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 13, 2017 at 7:26 PM, Ben Gamari <span dir="ltr"><<a href="mailto:ben@well-typed.com" target="_blank">ben@well-typed.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Edward Kmett <<a href="mailto:ekmett@gmail.com">ekmett@gmail.com</a>> writes:<br>
<br>
> That, rather tangentially, reminds me: If we do start to teach the code<br>
> generator about how to produce these sorts of things from simpler parts,<br>
> e.g. via enabling something like LLVM's vectorization pass, or some<br>
> internal future ghc compiler pass that checks for, say, Superword-Level<br>
> Parallelism<br>
</span>> <<a href="http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.106.4663&rep=rep1&type=pdf" rel="noreferrer" target="_blank">http://citeseerx.ist.psu.edu/<wbr>viewdoc/download?doi=10.1.1.<wbr>106.4663&rep=rep1&type=pdf</a>><br>
<span class="">> in the style of Jaewook Shin, then we need to differentiate between flags<br>
> for what ghc/llvm is allowed to produce via optimization, etc. and what the<br>
> end user is allowed to explicitly emit. e.g. in my own code I can safely<br>
> call avx2 primitives after I set up guards to check that I'm on a CPU that<br>
> supports them, but I can only currently emit that code after I tell GHC<br>
> that I want it to allow the avx2 instructions. If I build a complicated<br>
> dispatch mechanism in Haskell for picking the right ISA and emitting code<br>
> for several of them, I'm going to need to tell ghc to let me build with all<br>
> sorts of instruction sets that the machine the final executable runs on may<br>
> not fully support. We should be careful not to conflate these two things.<br>
><br>
</span>Indeed this is tricky.<br>
<br>
The obvious stop-gap solution is to simply move your various platform<br>
dependent implementations into multiple modules. However, as you say<br>
this quickly breaks down once GHC itself starts to learn vectorisation.<br>
At that point you will need to draw the distinction you mention,<br>
separating the ISA available to the user and that available to the<br>
compiler.<br>
<br>
Another related question is whether you eventually want a way to specify<br>
an ISA per-function (via pragma, for instance). This would allow you to<br>
set a conservative `-march` for the module on the whole, but allow use<br>
of ISA extensions precisely when necessary. This is a bit tricky in the<br>
face of inlining; perhaps you want to require only `NOINLINE` functions<br>
can be decorated with such a thing.<br>
<br>
I suspect in the case of LLVM this will require breaking modules up into<br>
multiple compilation units and linking together the resulting objects.<br>
This will certainly require a fair bit of engineering effort but nothing<br>
terribly difficult.<br>
<br>
Regarding dispatch, GCC has a function multi-versioning mechanism [1]<br>
which is seems relevant to mention here. However, it's not entirely<br>
clear to me whether the complexity here is worthwhile for GHC.<br>
<br>
Anyways, there are plenty of possible options here; it would be helpful<br>
to have a feature request ticket for the "user/compiler ISA" idea you<br>
propose where we can collect ideas. Perhaps you could open one?<br>
<br>
Cheers,<br>
<br>
- Ben<br>
<br>
<br>
[1] <a href="https://lwn.net/Articles/691666/" rel="noreferrer" target="_blank">https://lwn.net/Articles/<wbr>691666/</a><br>
</blockquote></div><br></div>