similar to: [LLVMdev] SSE intrinsic alignment bug?

The intent here is that "in" and "out" are always aligned, by forcing the stack pointer in the function that defines them to be aligned. On some targets (darwin) the stack pointer is always 16-byte aligned; on other targets there should be code in the function prologue to force it to be aligned. On May 22, 2008, at 4:36 PM, Nicolas Capens wrote: > Small typo, for

Small typo, for the correct assembly code I meant: mov eax,dword ptr [esp+8] movups xmm0,xmmword ptr [eax] rcpps xmm1,xmm0 mov eax,dword ptr [esp+4] movups xmmword ptr [eax],xmm1 ret -------------- next part -------------- An HTML attachment was scrubbed... URL:

Yep, I'm fixing it (and others) now. Good catch. Evan On May 22, 2008, at 4:59 PM, Dan Gohman wrote: > > On May 22, 2008, at 4:24 PM, Nicolas Capens wrote: >> >> >> Since I’m fairly new to LLVM I’m not entirely sure if this is really >> a bug or something I’m not doing correctly, or whether it’s already >> being addressed. The following thread appears to

Hi all, I think I found a regression in the shuffle instruction. I've attached a replacement of fibonacci.cpp to reproduce the issue. It runs fine on release 2.3 but revision 52648 fails, and I suspect that the issue is still present. 2.3 generates the following x86 code: 03A10010 push ebp 03A10011 mov ebp,esp 03A10013 and esp,0FFFFFFF0h 03A10019

Hi all, It looks like vector spills don't use aligned moves even though the stack is aligned. This seems like an optimization opportunity. The attached replacement of fibonacci.cpp generates x86 code like this: 03A70010 push ebp 03A70011 mov ebp,esp 03A70013 and esp,0FFFFFFF0h 03A70019 sub esp,1A0h ... 03A7006C movups xmmword ptr

Hi all, The InstructionCombining pass causes alignment of globals to be ignored. I've attached a replacement of Fibonacci.cpp which reproduces this (I used 2.3 release). Here's the x86 code it produces: 03C20019 movaps xmm0,xmmword ptr ds:[164E799h] 03C20020 mulps xmm0,xmmword ptr ds:[164E79Ah] 03C20027 movaps xmmword ptr ds:[164E799h],xmm0 03C2002E

Hello LLVMers, High order bit: Presence of a called function is causing a store on an unrelated vector to generate an aligned store rather an unaligned one despite unaligned store being indicated in the associated StoreInst. Details: I pulled down the latest source, so this is something I'm finding with the current LLVM. I'm hoping you'll have an idea what's

I have fixed a related bug: 52740. Can you check if that fixes this problem? Evan On Jul 11, 2008, at 6:43 PM, Nicolas Capens wrote: > Hi all, > > I think I found a regression in the shuffle instruction. I’ve > attached a replacement of fibonacci.cpp to reproduce the issue. It > runs fine on release 2.3 but revision 52648 fails, and I suspect > that the issue is still

This is on Windows / Cygwin? I think the dynamic stack pointer re- alignment doesn't happen until post- register allocation. Assuming there aren't other instructions between the prologue and the first movups that mess up esp (there shouldn't), this is indeed a bug. Please file a bug and attach a bc file. Thanks. Evan On Jul 14, 2008, at 7:43 AM, Nicolas Capens wrote: > Hi

On Oct 18, 2007, at 1:52 PM, Chuck Rose III wrote: > > Here are the instructions for evaluateDependents. The JITter > hasn’t compiled foo yet. What’s confusing to me is why did my > movups suddenly become a movaps? All the stores and loads have > align 1 on them. Hi Chuck, I believe this is a bug but am unable to reproduce it with the test case you've provided. I

On May 22, 2008, at 4:24 PM, Nicolas Capens wrote: > > > Since I’m fairly new to LLVM I’m not entirely sure if this is really > a bug or something I’m not doing correctly, or whether it’s already > being addressed. The following thread appears to talk about > something similar:http://thread.gmane.org/gmane.comp.compilers.llvm.devel/9476/focus=9478 Looking at LLVM's

Fixed. Evan On May 22, 2008, at 5:02 PM, Evan Cheng wrote: > Yep, I'm fixing it (and others) now. Good catch. > > Evan > > On May 22, 2008, at 4:59 PM, Dan Gohman wrote: > >> >> On May 22, 2008, at 4:24 PM, Nicolas Capens wrote: >>> >>> >>> Since I’m fairly new to LLVM I’m not entirely sure if this is really >>> a bug or

On Jul 14, 2008, at 7:43 AM, Nicolas Capens wrote: > Hi all, > > It looks like vector spills don’t use aligned moves even though the > stack is aligned. This seems like an optimization opportunity. What target is this? Linux doesn't have a 16-byte aligned stack. -Chris > > The attached replacement of fibonacci.cpp generates x86 code like > this: > > 03A70010

Hi Evan, Could you maybe point me to the source files where this issue might originate? I'd like to learn more about LLVM's innards but so far I've just scraped the surface and I don't know where what phase of instruction selection / register allocation / stack layout / etc. happens. If I understand correctly this issue might be fixed by moving stack pointer alignment

Hi, I found that llvm.exp.f32 didn't work but sqrt works well. I implemented a function like define inlinehint float "my_exp"(float %.value) { .body: %0 = call float @llvm.exp.f32(float %.value) ret float %0 } declare float @llvm.exp.f32(float) nounwind readonly But it generates following ASM: 00280072 movups xmm0,xmmword ptr [esp+8] 00280077 movss dword ptr

Hi all, I'd like to make use of some specific x86 Streaming SIMD Extension instructions, but I don't know where to start. For instance the 'rcpps' instructions computes a low precision but fast reciprocal. I've noticed that LLVM supports intrinsics, but I couldn't find any information on how to use them. I've tried digging through the LLVM-GCC code but it's just

On Tue, May 20, 2008 at 5:03 AM, Nicolas Capens <nicolas at capens.net> wrote: > LoadInst *x = new LoadInst(ptr_x, "", false, basicBlock); > > // y = rcpps(x) // FIXME > StoreInst *storeResult = new StoreInst(y, ptr_y, false, basicBlock); Using an IRBuilder, something like the following (uncompiled, but it's at least approximately right): Value* x =

I think I found it. In InstCombiner::ComputeMaskedBits we have the following lines: if (GlobalValue *GV = dyn_cast<GlobalValue>(V)) { unsigned Align = GV->getAlignment(); if (Align == 0 && TD && GV->getType()->getElementType()->isSized()) Align = TD->getPrefTypeAlignment(GV->getType()->getElementType()); It assumes that global

Hi, I'm new to LLVM and have some questions about using the JIT on Windows x64. I am aware that this is currently broken but am attempting to use the hack/patch proposed in this bug http://llvm.org/bugs/show_bug.cgi?id=3739. I checked out the revision the patch was created for (66183) and applied it but the assembler generated seems to fail whenever it reaches a movaps insctruction.

Objects compiled for the MS-ABI don't conform to it! Data types beyond 64 bit MUST BE returned by the callee via the hidden first argument allocated by the caller, NOT in XMM0! Demo/proof: from this source --- llvm-bug.c --- #ifndef __clang__ typedef struct { unsigned __int64 low; unsigned __int64 high; } __uint128_t; #else __attribute__((ms_abi)) #endif __uint128_t