similar to: [LLVMdev] How to force stack alignment for particular target triple in JIT?

Hi Yuri, > I get SEGV in gcc-compiled procedure in Solaris10-i386. This procedure > is called from llvm JIT code. > Exact instruction that crashes is this: movdqa %xmm0, 0x10(%esp) > %esp is 8-aligned, and by definition of movdqa it expects 16-aligned stack. > This leads me to believe that llvm uses wrong ABI when calling external > procedures and doesn't align stack

On 02/20/2011 23:50, Duncan Sands wrote: > Hi Yuri, > > >> I get SEGV in gcc-compiled procedure in Solaris10-i386. This procedure >> is called from llvm JIT code. >> Exact instruction that crashes is this: movdqa %xmm0, 0x10(%esp) >> %esp is 8-aligned, and by definition of movdqa it expects 16-aligned stack. >> This leads me to believe that llvm uses

On Sun, Feb 20, 2011 at 09:16:56PM -0800, Yuri wrote: > Isn't target triple supposed to set correct ABI including stack > alignment? How to set the correct alignment for this triple? OSX uses 16 Byte. Linux silently changed the SYSV ABI to 16 Byte alignment as well. The most likely candidate is that all other ELF platforms simply inherited this change. Joerg

Jonathan, Here's the code difference we see with the recent change -- what amounts to reverting your change from a couple years back. It doesn't look like we're getting superfluous instructions from clang now. the bad behavior for us was the alignment exception on the movdqa instructions when the input data wasn't 128-bit aligned. We had to change something because the code as-is

On May 10, 2010, at 9:07 PM, NAKAMURA Takumi wrote: > Hello. This is my 1st post. ようこそ！ > I have tried SSE execution domain fixup pass. > But I am not able to see any improvements. Did you actually measure runtime, or did you look at assembly? > I expect for the example below to use MOVDQA, PAND &c. > (On nehalem, ANDPS is extremely slower than PAND) Are you sure? The

the clang 3.5 loop optimizer seems to jump in unintentional for simple loops the very simple example ---- const int SIZE = 3; int the_func(int* p_array) { int dummy = 0; #if defined(ITER) for(int* p = &p_array[0]; p < &p_array[SIZE]; ++p) dummy += *p; #else for(int i = 0; i < SIZE; ++i) dummy += p_array[i]; #endif return dummy; } int main(int argc, char** argv) {

Hello. This is my 1st post. I have tried SSE execution domain fixup pass. But I am not able to see any improvements. I expect for the example below to use MOVDQA, PAND &c. (On nehalem, ANDPS is extremely slower than PAND) Please tell me if something would be wrong for me. Thank you. Takumi Host: i386-mingw32 Build: trunk at 103373 foo.ll: define <4 x i32> @foo(<4 x i32> %x,

Hello, Depending on how I extract integer lanes from an x86_64 xmm register, the backend may spill that register in order to load scalars. The effect was observed on two targets: corei7-avx and btver1 (I haven't checked other targets). Here's a test case with spilling/no-spilling code put on conditional compile: #if __SSE4_1__ != 0 #include <smmintrin.h> #else #include

I am new to LLVM, and I'm trying to compile llvm and llvm-gcc from subversion on a Solaris10/SPARC machine. I have already tried building llvm-2.4 on this machine, but it failed. I then tried the subversion sources (rev. # 65253 fro llvm and rev#65263 for llvm-gcc) and llvm at least builds correctly ( I however have not tried testing it!). I can execute binaries located in

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

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

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

Hi all, My Machine environment is Clang-2.8-svn on Linux-x86. When I build ffmpeg-0.6 using Clang, error output: CC libavcodec/x86/mpegvideo_mmx.o fatal error: error in backend: Ran out of registers during register allocation! Please check your inline asm statement for invalid constraints: INLINEASM <es:movd %eax, %xmm3 pshuflw $$0, %xmm3, %xmm3 punpcklwd %xmm3, %xmm3

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 configure:17280: result: no configure:17300: checking for mblen configure:17356: gcc -o conftest -O3 -m64 -mtune=native -pipe -Wall -Wpointer-arith -Wuninitialized -Wsign-compare -Wformat-security -Wsizeof-pointer-memaccess -Wno-pointer-sign -Wno-unused-result -fno-strict-aliasing -D_FORTIFY_SOURCE=2 -ftrapv -fno-builtin-memset

Hi Michael, Sometime back I did some experiments with interleave vectorizer and did not found any degrade, probably my tests/benchmarks are not extensive enough to cover much. Elina is the right person to comment on it as she already experienced cases where it hinders performance. For interleave vectorizer on X86 we do not have any specific costing, it goes to BasicTTI where the costing is not

On 2009-02-24 03:28, Kshitij Sudan wrote: > I am new to LLVM, and I'm trying to compile llvm and llvm-gcc from > subversion on a Solaris10/SPARC machine. I have already tried building > llvm-2.4 on this machine, but it failed. > > I then tried the subversion sources (rev. # 65253 fro llvm and > rev#65263 for llvm-gcc) and llvm at least builds correctly ( I however > have

I am running into a problem with 'i1*' as a function's argument which seems to have appeared since I switched to LLVM 3.6 (but can have other source, of course). If I look at the assembler that the MCJIT generates for an x86-64 target I see that the array 'i1*' is taken as a sequence of 1 bit wide elements. (I guess that's correct). However, I used to call the function

Hm, yes — with the current Xcode clang (Xcode 8.3.3, Apple LLVM version 8.1.0 (clang-802.0.42)), I don’t see any difference in the generated code with -O2 between the two versions. (Literally none for x86_64, and only what seem to be some non-signficiant offset changes for i386). So if this improves some other cases (notably, it should avoid problems with -fsanitize=address) I think this is

On Thu, Aug 3, 2017 at 6:19 PM, Tim Northover <t.p.northover at gmail.com> wrote: > 2017-08-03 8:58 GMT-07:00 Johan Engelen via llvm-dev < > llvm-dev at lists.llvm.org>: > > The error is gone after removing (or reducing) the alignment of `%a`. > This > > makes me believe that our inline asm syntax is correct to add an offset > to a > > pointer: "

We see the MOVQ instruction but this patch deliberately uses it rather than MOVQDA (load 128-bits aligned). We were seeing that with the trace below, the final invocation is not 128-bit aligned but MOVQDA insists on it (the calling function was pitch_sse4_1.c:90, in the 4-way N - i >= 4 loop). 07-31 11:00:13.469 210 2540 <(469)%20210-2540> D opus_sse1: RBE celt_inner_prod_sse4_1: x