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

[Hal Finkel]

----- Original Message -----
> From: "Philip Reames" <listmail at philipreames.com>
> To: "David Majnemer" <david.majnemer at gmail.com>
> Cc: "LLVMdev" <llvmdev at cs.uiuc.edu>
> Sent: Friday, June 26, 2015 1:20:32 PM
> Subject: Re: [LLVMdev] extractelement causes memory access violation - what to do?
> 
> 
> 
> 
> 
> 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 > 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 >
> 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.

Same here. isSafeToSpeculativelyExecute will be able to handle the constant-index case (any anything else for which ComputeKnownBits is helpful for range reduction). For the variable-index case, the frontend can either emit a mask or leave it as UB. I think that's the best solution.

 -Hal

> 
> Philip
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory