similar to: [LLVMdev] X86 SSE Intrinsics

Actually my problem is solved when I added "__sigsetjmp" to this list. Thanks, -Khaled On Tue, Oct 4, 2011 at 10:27 PM, Khaled ElWazeer <khalid.alwazeer at gmail.com>wrote: > > That code should do it, but I realized you only detect setjmp functions by > name. My code is calling "__sigsetjmp" not "segsetjmp". You only support > these functions:

That code should do it, but I realized you only detect setjmp functions by name. My code is calling "__sigsetjmp" not "segsetjmp". You only support these functions: static const char *ReturnsTwiceFns[] = { "_setjmp", "setjmp", "sigsetjmp", "setjmp_syscall", "savectx", "qsetjmp",

On Oct 4, 2011, at 3:53 PM, Eli Friedman wrote: > On Tue, Oct 4, 2011 at 3:10 PM, Khaled ElWazeer > <khalid.alwazeer at gmail.com> wrote: >> Hi, >> >> I have some code which has sigsetjmp / longjmp. After a longjmp, unreachable >> is inserted, which is fine. The problem is that in the backend before >> calling longjmp, some register was spilled to a

Hi, I have some code which has sigsetjmp / longjmp. After a longjmp, unreachable is inserted, which is fine. The problem is that in the backend before calling longjmp, some register was spilled to a stack location which is live across the jmp. I mean, it will be live after jumping. The stack location was initialized before the call to setjmp, and is used afterwards. Is there any bug in handling

On Tue, Oct 4, 2011 at 3:10 PM, Khaled ElWazeer <khalid.alwazeer at gmail.com> wrote: > Hi, > > I have some code which has sigsetjmp / longjmp. After a longjmp, unreachable > is inserted, which is fine. The problem is that in the backend before > calling longjmp, some register was spilled to a stack location which is live > across the jmp. I mean, it will be live after

> > SNIP > > Is there anyone who can help with this question? prism# net ads testjoin Join is OK That's about it. Pretty simple. > > > > Regards, > Khaled > > 2010/4/30 Khaled Blah <khaled.blah at googlemail.com>: >> >> Can anyone give me any hints please? I've read the man pages for >> smb.conf and for net and then I read the

On Oct 4, 2011, at 8:23 PM, Khaled ElWazeer wrote: > Actually my problem is solved when I added "__sigsetjmp" to this list. Rafael just added a returns_twice function attribute to LLVM IR. I expect he will update the callsFunctionThatReturnsTwice() function soon. /jakob

Actually, I prefer having the user explicitly specify --enable-sse because you might want to compile for other machines than what you have. Also, any idea what happens if the user already has CFLAGS=-O2 defined (and you add -O3)? Last thing, how do you check whether gcc accepts -msse? Jean-Marc Le ven 02/04/2004 à 00:40, Aron Rosenberg a écrit : > Here is code to add to configure.in

I'm aware of the problem, but I don't know how to get autoconf to handle that properly. If someone knows how to make that work with autoconf even with non-gcc compilers and with default CFLAGS, I'm interested. Jean-Marc Le jeu 01/04/2004 à 17:21, Michael T. Dean a écrit : > When compiling Speex 1.1.4 with GCC 3.3.2, the option -msse must be > added to the CFLAGS in

Hey guys, Is there a reason for the following naming quirk in the x86 SSE intrinsics: int_x86_sse2_pcmpeq_b int_x86_sse2_pcmpeq_w int_x86_sse2_pcmpeq_d int_x86_sse41_pcmpeqq I anticipated a "_q" suffix for the quadword variant, but was surprised to see the intrinsic named above. Just FYI..., Cameron -------------- next part -------------- An HTML attachment was scrubbed... URL:

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 =

On Fri, Jun 5, 2009 at 8:51 AM, David Greene<dag at cray.com> wrote: > def Int_CVTSD2SIrm : SDI<0x2D, MRMSrcMem, (outs GR32:$dst), (ins f128mem: > $src), >                         "cvtsd2si\t{$src, $dst|$dst, $src}", >                         [(set GR32:$dst, (int_x86_sse2_cvtsd2si >                                           (load addr:$src)))]>; > > Er,

On Friday 05 June 2009 15:19, Dan Gohman wrote: > > Do we need two intrinsics for these scalar converts, one to satisfy > > the > > (arguably broken) GCC interface and one to really reflect the > > operation > > as specified by the ISA? > > That's what's done for most other instructions, unfortunately. > For cvtsd2si, there's currently no

On Friday 05 June 2009 15:22, Eli Friedman wrote: > > Do we need two intrinsics for these scalar converts, one to satisfy the > > (arguably broken) GCC interface and one to really reflect the operation > > as specified by the ISA? > > We really need zero intrinsics... it's quite easy to map onto existing > LLVM instructions. See the definition of CVTSD2SIrm. In

On Jun 5, 2009, at 3:16 PM, David Greene wrote: > On Friday 05 June 2009 15:19, Dan Gohman wrote: > >> One thing we'd like to do at some point is have front-ends lower >> intrinsics for scalar instructions into >> extractelement+op+insertelement, so that we don't need two >> versions of each of the instructions. Doing this for everything >> will

On Fri, Jun 5, 2009 at 3:19 PM, David Greene<dag at cray.com> wrote: > On Friday 05 June 2009 15:22, Eli Friedman wrote: > >> > Do we need two intrinsics for these scalar converts, one to satisfy the >> > (arguably broken) GCC interface and one to really reflect the operation >> > as specified by the ISA? >> >> We really need zero intrinsics...

On Oct 9, 2009, at 1:26 PMPDT, David Greene wrote: > Ok, I've been looking at this for hours and can't figure it out. I > know I'm > missing something obvious. > > I've been spending the past few days beefing up the vector support > in the C > Backend. This should help us debug vector code that's miscompiled. > But > gcc doesn't like

On Friday 09 October 2009 15:47, Dale Johannesen wrote: > On Oct 9, 2009, at 1:26 PMPDT, David Greene wrote: > > Ok, I've been looking at this for hours and can't figure it out. I > > know I'm > > missing something obvious. > > > > I've been spending the past few days beefing up the vector support > > in the C > > Backend. This should

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

Ok, I've been looking at this for hours and can't figure it out. I know I'm missing something obvious. I've been spending the past few days beefing up the vector support in the C Backend. This should help us debug vector code that's miscompiled. But gcc doesn't like this fragment: ((double *)(&llvm_cbe_r1147))[0u] = (((llvm_cbe_r1146__BITCAST_TEMPORARY.Int64 =