<div class="gmail_quote">On 8 February 2012 08:43, David A. Greene <span dir="ltr"><<a href="mailto:dag@cray.com">dag@cray.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im">Duncan Sands <<a href="mailto:baldrick@free.fr">baldrick@free.fr</a>> writes:<br>
<br>
>> My experience with the C backend says otherwise.  I've run across lots<br>
>> of cases where shuffles could not be handled.<br>
><br>
> then fix the C backend?<br>
<br>
</div>Not possible with the current C backend.  It uses illegal types, for<br>
one.<br>
<div class="im"><br>
>> I don't know of any way to generate generic IR and guarantee that the<br>
>> instruction the user selected through an intrinsic will be the<br>
>> instruction selected by LLVM's isel.  There are too many transformation<br>
>> steps in-between.<br>
><br>
> Of course there is no such guarantee.  The question is whether doing things<br>
> using generic IR is mostly a win or not.  Maybe today it's often not a win,<br>
> but since that's fixable it seems to me that the "use generic IR if not too<br>
> crazy" path is on the whole the right way to go.<br>
<br>
</div>Whether generic IR is a "win" isn't the primary issue here.  The issue<br>
is that the user wrote code using intrinsics and expects that exact code<br>
to be in the asm.  Whether or not that is the best performing code<br>
possible doesn't matter.  It's what they want and we have to respect it.<br>
Our customers demand it.<br></blockquote><div><br></div><div>Okay. This is a different issue then, and isn't even solved by using intrinsics; the optimization passes are absolutely allowed to modify uses of intrinsics. We do this in obvious cases for things like memset or ctz, but there is no reason the optimization passes won't optimize the llvm.x86 intrinsics too. It's rare, but you can see code in ValueTracking.cpp that will analyze Intrinsic::x86_sse42_crc32_64_8 for one example, ConstantFolding.cpp will fold through x86_sse_cvtss2si for another.</div>

<div><br></div><div>Suppose you emit code like this: create your own functions with definitions that use the IR implementations, and mark them noinline. At the very end, you inline them with a pass that calls InlineFunction() directly. Does this preserve the order, or do you still have trouble with the backend doing too much reordering?</div>

<div><br></div><div>Nick</div><div><br></div></div>