[LLVMdev] extractelement causes memory access violation - what to do?

[Philip Reames]

On 06/26/2015 11:07 AM, David Majnemer wrote:
>
>
> On Fri, Jun 26, 2015 at 9:38 AM, Philip Reames 
> <listmail at philipreames.com <mailto:listmail at philipreames.com>> wrote:
>
>     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.
>
>
> The only problem that I can see by specifying it this way is that they 
> cannot be speculatively executed, isSafeToSpeculativelyExecute 
> believes it is currently safe to do so.  I can see why speculating 
> this instruction might be good. Perhaps we should emit a mask...
Hm, yuck.  Hadn't thought about that one.

One option would to let extractelements with provably in bounds entries 
be speculated, but not others.

Another option might be to have a mask emitted by the code that is 
speculating it.

I'm not sure how bad either scheme would actually be in practice. Almost 
all of the extractelements I see in optimized IR have constant indices.

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