similar to: crash with vector store

Using LLVM 2.9, the following LLVM IR produces invalid x86 32 bit assembly (a misaligned SSE store). ; ModuleID = 'MisalignedStore' define void @MisalignedStore() nounwind readnone { entry: %v = alloca <4 x float>, align 16 store <4 x float> zeroinitializer, <4 x float>* %v, align 16 br label %post-block post-block: %f = alloca float ret void } If I feed

I'm trying to make a security sandbox. For example, lets say my program has a LoadInst in the LLVM IR and I know I want to confine the address range this LoadInst is accessing. Maybe that LoadInst gets emitted as a MOV machine code instruction by the backend. During execution an attacker could potentially control the operands of the MOV instruction through some exploit, but usually he

Hi, I had successfully set up dovecot-1.0-test62 + ldap pass/user db, but now I'm encoutering a SIGSEV problem with a similar set up of a brand new dovecot-1.0-test65 installation. The auth process is killed by a SIGSEV as reported in the error log file : dovecot: Mar 30 17:06:59 Error: child 28291 (auth) killed with signal 11 To be precise, the problem occurs in the

On Fri, Jul 6, 2012 at 6:39 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > > On Jul 5, 2012, at 9:06 PM, Anthony Blake <amb33 at cs.waikato.ac.nz> wrote: > >> I've noticed that LLVM tends to generate suboptimal code and spill an >> excessive amount of registers in large functions, such as in those >> that are automatically generated by FFTW. >

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

On Sat, Jul 7, 2012 at 12:25 AM, Anthony Blake <amb33 at cs.waikato.ac.nz> wrote: > On Fri, Jul 6, 2012 at 6:39 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: >> On Jul 5, 2012, at 9:06 PM, Anthony Blake <amb33 at cs.waikato.ac.nz> wrote: >>> [...] >>> movaps 32(%rdi), %xmm3 >>> movaps 48(%rdi), %xmm2 >>>

I don't know how to file a PR, but I have a patch (see below), that should work regardless of abi differences, since it relies on the compiler to do the though job. void X86CompilationCallback_SSE(void) { char * SAVEBUF= (char*) alloca(64+12); // alloca is 16byte aligned asm volatile ( "movl %%eax,(%0)\n" "movl %%edx,4(%0)\n" // Save EAX/EDX/ECX

Hello. I found that the X86CompilationCallback_SSE wrapper for X86CompilationCallback2 is not setting up properly for the PIC invocation. Before you can correctly invoke a function via the Procedure Linkage Table (plt), the ABI mandates that ebx is pointing to the GOT (Global Offset Table) (see http://www.greyhat.ch/lab/downloads/pic.html) Dump of assembler code for function

Hello, Corrado > Before you can correctly invoke a function via the Procedure Linkage > Table (plt), the ABI mandates that ebx is pointing to the GOT (Global > Offset Table) (see http://www.greyhat.ch/lab/downloads/pic.html) This is known issue, just nobody realized, that we have bunch of non- PIC-aware assembler code. :) Fixing would be not so trivial though, mostly due to ABI

On Thu, Nov 10, 2011 at 6:13 PM, Aaron Dwyer <Aaron.Dwyer at imgtec.com> wrote: > Using LLVM 2.9, the following LLVM IR produces invalid x86 32 bit assembly > (a misaligned SSE store). > ; ModuleID = 'MisalignedStore' > define void @MisalignedStore() nounwind readnone { > entry: >   %v = alloca <4 x float>, align 16 >   store <4 x float>

hi, I am just playing a bit with the dovecot SASL plugin for postfix and so far my tests have been very successfull, can't wait to get the cyrus-sasl beast replaced. However, I found a potential problem when doing some "illegal" stuff on the postfix side: -------CUT------- cerberus:/var/log# telnet smtptest 25 Trying 192.168.99.99... Connected to smtptest.bestsolution.at. Escape

On Tuesday 02 September 2008 16:47, Evan Cheng wrote: > On Sep 2, 2008, at 10:42 AM, David Greene wrote: > > Is there an easy way to get the MVT::ValueType of a MachineInstruction > > MachineOperand? For example, the register operand of an x86 MOVAPD > > should > > have an MVT::ValueType of v2f64. A MOVAPS register operand should > > have an > >

Hi, I've noticed that LLVM tends to generate suboptimal code and spill an excessive amount of registers in large functions, such as in those that are automatically generated by FFTW. LLVM generates good code for a function that computes an 8-point complex FFT, but from 16-point upwards, icc or gcc generates much better code. Here is an example of a sequence of instructions from a 32-point

On Jul 5, 2012, at 9:06 PM, Anthony Blake <amb33 at cs.waikato.ac.nz> wrote: > I've noticed that LLVM tends to generate suboptimal code and spill an > excessive amount of registers in large functions, such as in those > that are automatically generated by FFTW. One problem might be that we're forcing the 16 stores to the out array to happen in source order, which

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

Hello, Simon > So far, i found no way to denote calls to the host function as aligned > or maintain stack alignment throughout the stack frame of the jit > compiled function. Further, the gcc front end (llvm-g++ (GCC) 4.2.1) > seems to ignore directives such as -mpreferred-stack-boundary. Mike is right. It depends on your subtarget: 1. If you're running stuff on Darwin, which has

Hi all, i am trying to call an aligned function in my host application from jit compiled bitcode. The call itself is done using an absolute pointer to the function. The host application's functions make heavy use of SSE instructions and are thus operate on a stack aligned to 16 byte. If i call an aligned function in the host application from a frame running jit compiled code, the alignment

It's not reproducible with 'opt'. I call the SLP pass from my application and only then the wrong IR gets generated. On the attached module I call via the function pass manager: 1) TargetLibraryInfo with the target triple 2) Set the data layout 3) Basic Alias Analysis 4) SLP vectorizer This produces the wrong IR. On the other hand running the attached module through 'opt

Hello, Nathan > or if it should be a configure test, which might be safer. Are there > any x86 platforms (other than apple) that don't need PLT-indirect calls? Yes, mingw. However just tweaking the define is not enough - we're not loading address of GOT into ebx before the call (on 32 bit ABIs) thus the call will be to nowhere. -- With best regards, Anton Korobeynikov Faculty of

On Thu, Aug 1, 2019 at 6:09 PM JF Bastien <jfbastien at apple.com> wrote: > > Hi Alexander, > > The code doesn’t compile. Could you send a godbolt.org link that shows the issue? Sorry about that, here's the link: https://godbolt.org/z/-PinQP Lines 4 to 8 are initializing |acpar|. If I'm understanding correctly, the store to 8(%rsp) at line 7 can be removed because of the