Re: [pocl-devel] POCL Crash in vmovaps operation

[Pekka J. (T. <pek...@tu...>]

Yes, now that I look at it more closely,
your stack trace looks _very_ much to the common data alignment
issues people have. I think this might be worth a FAQ item somewhere.

https://stackoverflow.com/questions/5983389/how-to-align-stack-at-32-byte-boundary-in-gcc

On 6.3.2019 8.45, Pekka Jääskeläinen (TAU) wrote:
> Hi Timo,
> 
> Shooting in the dark here, but since just yesterday I debugged a similar 
> looking issue
> which was caused by an illegal cast in the source code from float* to 
> float4*. It trusted
> the alignment is still fine, which it wasn't after vectorization. A very 
> target specific programming
> error which many ocl targets can easily hide.
> 
> If this is something else, we need a test case, smaller the better, to 
> help you here.
> Before opening an issue though, please with the latest master and LLVM 8.
> 
> Pekka
> 
> ------------------------------------------------------------------------
> *From:* Timo Betcke <tim...@gm...>
> *Sent:* Tuesday, March 5, 2019 11:27:12 PM
> *To:* Portable Computing Language development discussion
> *Subject:* [pocl-devel] POCL Crash in vmovaps operation
> Dear Pocl community,
> 
> I was just testing the newest Pocl Version (github master branch) with 
> our software. During execution of one of our kernels Pocl crashed. 
> Disassembling the crash shows the following operations during the crash:
> 
> ------------------
>     0x00007fffb81efdd8 <+664>:   vmulpd xmm2,xmm2,xmm6
>     0x00007fffb81efddc <+668>:   vsubpd xmm2,xmm5,xmm2
>     0x00007fffb81efde0 <+672>:   vpermilpd xmm5,xmm4,0x1
>     0x00007fffb81efde6 <+678>:   vmulsd xmm3,xmm3,xmm5
>     0x00007fffb81efdea <+682>:   vmulsd xmm4,xmm15,xmm4
>     0x00007fffb81efdee <+686>:   vsubsd xmm3,xmm3,xmm4
>     0x00007fffb81efdf2 <+690>:   vpermilpd xmm1,xmm1,0x1
>     0x00007fffb81efdf8 <+696>:   vmulpd xmm0,xmm0,xmm1
>     0x00007fffb81efdfc <+700>:   vpermilpd xmm1,xmm0,0x1
>     0x00007fffb81efe02 <+706>:   vsubsd xmm0,xmm0,xmm1
>     0x00007fffb81efe06 <+710>:   lea    rsi,[rdx+rdx*2]
>     0x00007fffb81efe0a <+714>:   mov    rdx,QWORD PTR [rbx+0x38]
> => 0x00007fffb81efe0e <+718>:   vmovaps XMMWORD PTR [rdx+rsi*8],xmm12
> ---Type <return> to continue, or q <return> to quit---
>     0x00007fffb81efe13 <+723>:   mov    QWORD PTR [rbx+0x40],rsi
>     0x00007fffb81efe17 <+727>:   mov    QWORD PTR [rdx+rsi*8+0x10],0x0
>     0x00007fffb81efe20 <+736>:   vinsertf32x4 ymm1,ymm16,xmm0,0x1
> -----------------------------
> This seems to be a similar bug that I discussed a year ago on the 
> mailing list. See the thread here: 
> https://www.mail-archive.com/poc...@li.../msg01087.html. 
> In summary, the issue was related to us using arrays of arrays within 
> our kernels and pocl creating wrong code for it.
> 
> During that time a gist was suggested for Pocl, which I tested but did 
> not improve things. Afterwards I let it drop for a while as we were in 
> early development and had loads of building sites. But our software is 
> now close to release ready and it would be great to get it working with 
> pocl.
> 
> Any help would be greatly appreciated.
> Best wishes
> 
> Timo
> 
> -- 
> Timo Betcke
> Professor of Computational Mathematics
> University College London
> Department of Mathematics
> E-Mail: t.b...@uc... <mailto:t.b...@uc...>
> Tel.: +44 (0) 20-3108-4068
> 
> 
> _______________________________________________
> pocl-devel mailing list
> poc...@li...
> https://lists.sourceforge.net/lists/listinfo/pocl-devel
> 

-- 
Pekka