<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 3 June 2015 at 11:28, Manu via Digitalmars-d <span dir="ltr"><<a href="mailto:digitalmars-d@puremagic.com" target="_blank">digitalmars-d@puremagic.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 3 June 2015 at 17:50, Jacob Carlborg via Digitalmars-d<br>
<span class=""><<a href="mailto:digitalmars-d@puremagic.com">digitalmars-d@puremagic.com</a>> wrote:<br>
> On 2015-06-03 01:08, Manu via Digitalmars-d wrote:<br>
><br>
>> It's fairly large to cover everything I think is important, and<br>
>> there's a few tools missing still; I can't finish without some way to<br>
>> know the SIMD flags fed to the compiler from the command line (some<br>
>> standard versions?), and it's also difficult to resolve without<br>
>> forceinline of some sort.<br>
><br>
><br>
> Isn't it possible to proceed without forceinline, to be able to finish the<br>
> functionality. I understand that you think it's useless for performance<br>
> reasons, but is it enough to get the functionality correct?<br>
<br>
</span>The codegen is everything. Functionality is the easy part here ;)<br>
Most things are already correct, but I can't confidently proof out the codegen.<br>
The main blocker though is that I don't know what simd level the user<br>
requested on the command line. The library has no idea what hardware<br>
features to target without explicit statement by the user.<br>
<span class=""><br></span></blockquote><div> <br></div><div>Well, the compiler knows whether the types are supported natively at least, and you can probe this information using CTFE.<br></div></div><br></div></div>