Nadav,
You are right, ISPC may issue intrinsics as a result of AST selection.
Though I believe that we should stick to LLVM IR whenever is possible.
Intrinsics may appear to be boundaries for optimizations (on both data and
control flow) and are generally not optimizable. LLVM may improve over time
from performance stand point and we would benefit from it (or it may play
against us, like in this case). We can change out IR generation, but not in
favor of intrinsics (in long term, though we may use them as workaround, os
course).
I'm not sure that select is really a canonical form of this operation, as
it really assumes AND in this case. But this is a philosophical question,
so no point to argue :) In any case it should lead to more efficient code.
Which means that a) this transformation should not happen or b) code
generation for this instruction combination should be tuned. This should
benefit LLVM in general IMHO. It also may be the case that this just leads
to the bad code only in our specific environment, but at this point it
doesn't seems to be the case.
I'll try to come up with small SSE4 reproducer.
By the way, I'm curious, is the any reason why you focus on SSE4, not AVX?
Seems that vectorizer should care the most about the latest silicon.
Dmitry.
On Mon, Oct 21, 2013 at 10:18 PM, Nadav Rotem <nrotem at apple.com> wrote:
> Hi Dmitry,
>
> ISPC does some instruction selection as part of vectorization (on ASTs!)
> by placing intrinsics for specific operations. The SEXT to i32 pattern was
> implemented because LLVM did not support vector-selects when this code was
> written.
>
> Can you submit a small SSE4 test case that demonstrates the problem?
> Select is the canonical form of this operations, and SEXT is usually more
> difficult to lower.
>
> Thanks,
> Nadav
>
> On Oct 21, 2013, at 11:12 AM, Dmitry Babokin <babokin at gmail.com>
wrote:
>
> Nadav,
>
> You are absolutely right, it's ISPC workload. I've checked SSE4 and
it's
> also severely affected.
>
> We use intrinsics only for conversion <N x i32> <=> i32, i.e.
movmsk.ps.
> For the rest we use general LLVM instructions. And I actually would really
> like to stick this way. We rely on LLVM's ability to produce efficient
code
> from general LLVM IR. Relying on intrinsics too much would be a crunch and
> a path to nowhere for many reasons :)
>
> What is the reason for this transformation, if it doesn't lead to
> efficient code?
>
> Dmitry.
>
>
>
> On Mon, Oct 21, 2013 at 7:01 PM, Nadav Rotem <nrotem at apple.com>
wrote:
>
>> Hi Dmitry.
>>
>> This looks like an ISPC workload. ISPC works around a limitation in
>> selection dag which does not know how to legalize mask types when both
128
>> and 256 bit registers are available. ISPC works around this problem by
>> expanding the mask to i32s and using intrinsics. Can you please verify
that
>> this regression only happens on AVX ? Can you change ISPC to use
intrinsics
>> ?
>>
>> Thanks
>> Nadav
>>
>> Sent from my iPhone
>>
>> > On Oct 21, 2013, at 4:04, Dmitry Babokin <babokin at
gmail.com> wrote:
>> >
>> > Nadav,
>> >
>> > Could you please have a look at bug #16941 and let us know what
you
>> think about it? It's performance regression after one of your
commits.
>> >
>> > Thanks.
>> >
>> > Dmitry.
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20131021/5209cc70/attachment.html>