llvm dev - Jun 2015 - [LLVMdev] extractelement causes memory access violation - what to do?

Hi,

Let's have a simple program:
define i32 @main(i32 %n, i64 %idx) {
  %idxSafe = trunc i64 %idx to i5
  %r = extractelement <4 x i32> <i32 -1, i32 -1, i32 -1, i32 -1>,
i64 %idx
  ret i32 %r
}

The assembly of that would be:
pcmpeqd %xmm0, %xmm0
movdqa %xmm0, -24(%rsp)
movl -24(%rsp,%rsi,4), %eax
retq

The language reference states that the extractelement instruction produces
undefined value in case the index argument is invalid (our case). But the
implementation simply dumps the vector to the stack memory, calculates the
memory offset out of the index value and tries to access the memory. That
causes the crash.

The workaround is to trunc the index value before extractelement (see
%idxSafe). But what should be the ultimate solution?

- PB
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150626/ad5c4f3d/attachment.html>

On Fri, Jun 26, 2015 at 7:00 AM, Paweł Bylica <chfast at gmail.com> wrote:
> Hi,
>
> Let's have a simple program:
> define i32 @main(i32 %n, i64 %idx) {
>   %idxSafe = trunc i64 %idx to i5
>   %r = extractelement <4 x i32> <i32 -1, i32 -1, i32 -1, i32
-1>, i64 %idx
>   ret i32 %r
> }
>
> The assembly of that would be:
> pcmpeqd %xmm0, %xmm0
> movdqa %xmm0, -24(%rsp)
> movl -24(%rsp,%rsi,4), %eax
> retq
>
> The language reference states that the extractelement instruction produces
> undefined value in case the index argument is invalid (our case). But the
> implementation simply dumps the vector to the stack memory, calculates the
> memory offset out of the index value and tries to access the memory. That
> causes the crash.
>
> The workaround is to trunc the index value before extractelement (see
> %idxSafe). But what should be the ultimate solution?
>
We could fix this by specifying that out of bounds access on an
extractelement leads to full-on undefined behavior, no need to force
everyone to eat the cost of a mask.

>
> - PB
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150626/9c780f96/attachment.html>

On 06/26/2015 08:42 AM, David Majnemer wrote:
>
>
> On Fri, Jun 26, 2015 at 7:00 AM, Paweł Bylica <chfast at gmail.com 
> <mailto:chfast at gmail.com>> wrote:
>
>     Hi,
>
>     Let's have a simple program:
>     define i32 @main(i32 %n, i64 %idx) {
>       %idxSafe = trunc i64 %idx to i5
>       %r = extractelement <4 x i32> <i32 -1, i32 -1, i32 -1, i32
-1>,
>     i64 %idx
>       ret i32 %r
>     }
>
>     The assembly of that would be:
>     pcmpeqd%xmm0, %xmm0
>     movdqa%xmm0, -24(%rsp)
>     movl-24(%rsp,%rsi,4), %eax
>     retq
>
>     The language reference states that the extractelement instruction
>     produces undefined value in case the index argument is invalid
>     (our case). But the implementation simply dumps the vector to the
>     stack memory, calculates the memory offset out of the index value
>     and tries to access the memory. That causes the crash.
>
>     The workaround is to trunc the index value before extractelement
>     (see %idxSafe). But what should be the ultimate solution?
>
>
> We could fix this by specifying that out of bounds access on an 
> extractelement leads to full-on undefined behavior, no need to force 
> everyone to eat the cost of a mask.
This seems like the appropriate decision to me.  It's closely in line 
with existing practice and assumptions.

Philip
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150626/4d44fda7/attachment.html>

On Fri, Jun 26, 2015 at 5:42 PM David Majnemer <david.majnemer at
gmail.com>
wrote:
> On Fri, Jun 26, 2015 at 7:00 AM, Paweł Bylica <chfast at gmail.com>
wrote:
>
>> Hi,
>>
>> Let's have a simple program:
>> define i32 @main(i32 %n, i64 %idx) {
>>   %idxSafe = trunc i64 %idx to i5
>>   %r = extractelement <4 x i32> <i32 -1, i32 -1, i32 -1, i32
-1>, i64 %idx
>>   ret i32 %r
>> }
>>
>> The assembly of that would be:
>> pcmpeqd %xmm0, %xmm0
>> movdqa %xmm0, -24(%rsp)
>> movl -24(%rsp,%rsi,4), %eax
>> retq
>>
>> The language reference states that the extractelement instruction
>> produces undefined value in case the index argument is invalid (our
case).
>> But the implementation simply dumps the vector to the stack memory,
>> calculates the memory offset out of the index value and tries to access
the
>> memory. That causes the crash.
>>
>> The workaround is to trunc the index value before extractelement (see
>> %idxSafe). But what should be the ultimate solution?
>>
>
> We could fix this by specifying that out of bounds access on an
> extractelement leads to full-on undefined behavior, no need to force
> everyone to eat the cost of a mask.
>
I don't have preference for any of the solutions.

I have a side question. It is not stated explicitly in the reference but I
would assume the index of extractelement is processed as an unsigned value.
However, the DAG Builder extends the index with sext. Is it correct?

- PB
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150630/d2334fe2/attachment.html>