Philip Reames
2015-Jun-26 16:38 UTC
[LLVMdev] extractelement causes memory access violation - what to do?
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>
David Majnemer
2015-Jun-26 18:07 UTC
[LLVMdev] extractelement causes memory access violation - what to do?
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...> > Philip >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150626/b5a8972f/attachment.html>
Philip Reames
2015-Jun-26 18:20 UTC
[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 <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>