search for: add64

Hi, Let's say we have a 32-bit architecture where 64-bit additions are done using 2 operations. Instructions are defined as follow in TableGen: defm ADD64 : ALU32<"add", 1, 1, addc>; defm ADD64C : ALU32<"addrc", 1, 2, adde>; Let's assume that the carry bit is implicit and that the 2 operations must *always* be stuck together for the 64-bit add to work properly. Is there a default guarantee that nothing will e...

...-Quentin > > On Apr 15, 2013, at 2:02 PM, Francois Pichet <pichet2000 at gmail.com> wrote: > > Hi, > > Let's say we have a 32-bit architecture where 64-bit additions are done > using 2 operations. > > Instructions are defined as follow in TableGen: > defm ADD64 : ALU32<"add", 1, 1, addc>; > defm ADD64C : ALU32<"addrc", 1, 2, adde>; > > > Let's assume that the carry bit is implicit and that the 2 operations must > *always* be stuck together for the 64-bit add to work properly. > Is there a default g...

Using bundles here looks like a fragile way to handle that, IMHO. Really, using a pseudo instruction seems the best approach for you. For instance, you can match your add64 during isel with your pseudo instruction and expand it just before emitting the assembly file (add a pass using the hook: addPreEmitPass on your target). -Quentin On Apr 15, 2013, at 2:37 PM, Francois Pichet <pichet2000 at gmail.com> wrote: > > I really have to force them to stuck t...

On Apr 15, 2013, at 2:02 PM, Francois Pichet <pichet2000 at gmail.com> wrote: > Hi, > > Let's say we have a 32-bit architecture where 64-bit additions are done using 2 operations. > > Instructions are defined as follow in TableGen: > defm ADD64 : ALU32<"add", 1, 1, addc>; > defm ADD64C : ALU32<"addrc", 1, 2, adde>; > > > Let's assume that the carry bit is implicit and that the 2 operations must *always* be stuck together for the 64-bit add to work properly. > Is there a default guar...

...re looking for. -Quentin On Apr 15, 2013, at 2:02 PM, Francois Pichet <pichet2000 at gmail.com> wrote: > Hi, > > Let's say we have a 32-bit architecture where 64-bit additions are done using 2 operations. > > Instructions are defined as follow in TableGen: > defm ADD64 : ALU32<"add", 1, 1, addc>; > defm ADD64C : ALU32<"addrc", 1, 2, adde>; > > > Let's assume that the carry bit is implicit and that the 2 operations must *always* be stuck together for the 64-bit add to work properly. > Is there a default guar...

...On Apr 15, 2013, at 2:02 PM, Francois Pichet <pichet2000 at gmail.com> wrote: > >> Hi, >> >> Let's say we have a 32-bit architecture where 64-bit additions are done using 2 operations. >> >> Instructions are defined as follow in TableGen: >> defm ADD64 : ALU32<"add", 1, 1, addc>; >> defm ADD64C : ALU32<"addrc", 1, 2, adde>; >> >> >> Let's assume that the carry bit is implicit and that the 2 operations must *always* be stuck together for the 64-bit add to work properly. >> Is t...

...;s a sequence of instructions that looks like this before linear scan: ##### 2800 %reg1591<def> = SUB64rr %reg1591, %reg1589, %EFLAGS<imp-def,dead> ; srcLine 0 2808 %reg1591<def> = IMUL64rr %reg1591, %reg1055, %EFLAGS<imp-def,dead> ; srcLine 0 2816 %reg1591<def> = ADD64rr %reg1591, %reg1579, %EFLAGS<imp-def,dead> ; srcLine 0 2820 %reg1198<def> = LEA64r %reg1591, 1, %reg1574, 0 ; srcLine 0 ##### %reg1591 gets spilled by linear scan with all of the uses in the sequence above reused by the "spltting" code in LiveIntervals. Note especially...

...0 #define SIG_SHIFT 0 #define VERY_SMALL 1e-30 #define PSHR(a,shift) (a) #define SHR(a,shift) (a) #define SHL(a,shift) (a) #define SATURATE(x,a) (x) #define ADD16(a,b) ((a)+(b)) #define SUB16(a,b) ((a)-(b)) #define ADD32(a,b) ((a)+(b)) #define SUB32(a,b) ((a)-(b)) #define ADD64(a,b) ((a)+(b)) #define MULT16_16_16(a,b) ((a)*(b)) #define MULT16_16(a,b) ((a)*(b)) #define MAC16_16(c,a,b) ((c)+(a)*(b)) #define MULT16_32_Q11(a,b) ((a)*(b)) #define MULT16_32_Q13(a,b) ((a)*(b)) #define MULT16_32_Q14(a,b) ((a)*(b)) #define MULT16_32_Q15(a,b) ((a)*(b))...

...I32 > +; SI: S_ADD_I32 > +; SI: S_ADD_I32 > +; SI: S_ADD_I32 > define void @test16(<16 x i32> addrspace(1)* %out, <16 x i32> %a, <16 x i32> %b) { > entry: > %0 = add <16 x i32> %a, %b > @@ -117,8 +117,12 @@ entry: > } > > ; FUNC-LABEL: @add64 > -; SI-CHECK: S_ADD_U32 > -; SI-CHECK: S_ADDC_U32 > +; SI: S_ADD_U32 > +; SI: S_ADDC_U32 > + > +; EG-DAG: ADD_INT > +; EG-DAG: ADDC_UINT > +; EG-DAG: ADD_INT > define void @add64(i64 addrspace(1)* %out, i64 %a, i64 %b) { > entry: > %0 = add i64 %a, %b > @@...

Hi Jean-Marc, Based on the wonderful Speex project, I've created SpeexOutLoud, essentially a Speex codec port for Windows Mobile 2003 devices. I've included a sample project intended to show the usage of SpeexOutLoud codec in a Pocket PC application based on .NET Compact Framework. I'd request you to please go through the attached build, and include it as a contribution to the

Hello, I am building the SPEC 2006 Benchmark with Clang as the compiler. I have written a function pass in LLVM and I am trying to run that for SPEC by invoking the pass in the build options of SPEC. The build options of SPEC are in a *.cfg config file, which allows us to specify the choice of compiler while building SPEC. (https://www.spec.org/cpu2006/Docs/install-guide-unix.html) The pass

...efine SATURATE16(x,a) (x) #define SATURATE32(x,a) (x) #define PSHR(a,shift) (a) #define SHR(a,shift) (a) #define SHL(a,shift) (a) #define SATURATE(x,a) (x) #define ADD16(a,b) ((a)+(b)) #define SUB16(a,b) ((a)-(b)) #define ADD32(a,b) ((a)+(b)) #define SUB32(a,b) ((a)-(b)) #define ADD64(a,b) ((a)+(b)) #define MULT16_16_16(a,b) ((a)*(b)) #define MULT16_16(a,b) ((spx_word32_t)(a)*(spx_word32_t)(b)) #define MAC16_16(c,a,b) ((c)+(spx_word32_t)(a)*(spx_word32_t)(b)) #define MULT16_32_Q11(a,b) ((a)*(b)) #define MULT16_32_Q13(a,b) ((a)*(b)) #define MULT16_32_Q14(a,b)...