similar to: [LLVMdev] Spilled variables using unaligned moves

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 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 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

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

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

Hmm, I'm not able to get those .ll files to compile if I disable SSE and I end up with SSE instructions(including sqrtpd) if I don't disable it. On Thu, Jul 18, 2013 at 10:53 PM, Peter Newman <peter at uformia.com> wrote: > Is there something specifically required to enable SSE? If it's not > detected as available (based from the target triple?) then I don't think

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

Hi all, I think I might have found a potential bug when using SSE intrinsic and unaligned memory. Here's the code to reproduce it: #include "llvm/Module.h" #include "llvm/Intrinsics.h" #include "llvm/Instructions.h" #include "llvm/ModuleProvider.h" #include "llvm/ExecutionEngine/JIT.h" #include

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

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:

(Changing subject line as diagnosis has changed) I'm attaching the compiled code that I've been getting, both with CodeGenOpt::Default and CodeGenOpt::None . The crash isn't occurring with CodeGenOpt::None, but that seems to be because ECX isn't being used - it still gets set to 0x7fffffff by one of the calls to 76719BA1 I notice that X86::SQRTPD[m|r] appear in

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 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

libFLAC have three SSE-accelerated functions FLAC__lpc_compute_autocorrelation_asm_ia32_sse_lag_N (N = 4, 8, 12). They require lpc_order less than N. The best compression preset (flac -8) uses lpc_order up to 12; it means that during encoding FLAC also uses unaccelerated C function. I'm not very familiar with asm so I took FLAC__lpc_compute_autocorrelation_asm_ia32_sse_lag_12, changed it and

On 9.3.2015 20:43, lvqcl wrote: > Janne Hyv?rinen wrote: > >> VLC 2.2.0 crashed with exception 0xc0000005 on the first file I tried. >> But libflac itself does not, for example flac.exe and foobar2000 have no >> issues. > *Very* interesting. > > I suspect that flac.exe and foobar2000 don't use > FLAC__lpc_restore_signal_16_intrin_sse2() function at all. This

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.

All, Attached is a patch that does two things. First it makes the use of the current SSE code a run time option through the use of speex_decoder_ctl() and speex_encoder_ctl It does this twofold. First there is a modification to the configure.in script which introduces a check based upon platform. It will compile in the sse assembly if you are on an i?86 based platform by making a

Jean-Marc, There is a big difference between SSE and SSEFP. The SSEFP means that the CPU supports the xmm registers. All Intel chips with SSE support do, however no current 32 bit AMD chips support the XMM registers. They will support the SSE instructions but not those registers. You are right about the SSE2 not being used. The AMD Opterons are the first AMD CPU's which support