similar to: [LLVMdev] How do I model MUL with multiply-accumulate instruction?

On Apr 16, 2009, at 2:19 PM, Greg McGary wrote: > The only multiplication instruction on my target CPU is > multiply-and-accumulate. The result goes into a special register that > can destructively read at the end of a sequence of multiply-adds. The > following sequence is required to so a simple multiply: > > acc r0 # clear accumulator, discarding its value (r0 reads as

On Apr 18, 2007, at 2:07 PM, Evan Cheng wrote: > > On Apr 18, 2007, at 11:25 AM, Christopher Lamb wrote: > >> I noticed that the TableGen code emitter generator assumes that >> the instruction fields are declared in the instruction format in >> the same order that operands are defined. This seems like a bad >> dependence to me, and that TableGen should match

Hey Sean, So the processor does in-memory computing, it reads instructions and operands from the memory array, performs the majority operations within the memory array itself. It does instructions using resistive majority which is AB'+B'C+AC Like it does AND operation as 1: 0, 1, @C; //C=0 2: 0, 1, @Binv; //Binv=0 3: 1, @B, @Binv; //Binv=B 4: @A, @Binv, @C; //C=A.B where each operation is

I have a back end which has both scalar and vector registers that alias each other. I'm having a problem generating the ISel from tablegen that appears only when a vector register class is declared to contain integer vectors. At that moment tablegen doesn't seem to be able to infer integer types in patterns that it was able to before, but I'm not clear on why that's the

On Sun, 22 Apr 2007, Christopher Lamb wrote: > I have a back end which has both scalar and vector registers that > alias each other. I'm having a problem generating the ISel from > tablegen that appears only when a vector register class is declared > to contain integer vectors. At that moment tablegen doesn't seem to > be able to infer integer types in patterns that it was

On Apr 18, 2007, at 11:25 AM, Christopher Lamb wrote: > I noticed that the TableGen code emitter generator assumes that the > instruction fields are declared in the instruction format in the > same order that operands are defined. This seems like a bad > dependence to me, and that TableGen should match the name of field > declared in the instruction with the name of the

I noticed that the TableGen code emitter generator assumes that the instruction fields are declared in the instruction format in the same order that operands are defined. This seems like a bad dependence to me, and that TableGen should match the name of field declared in the instruction with the name of the operand in order to determine which operand of the MI to use . See

Hello everyone, I was trying to create an LLVM backend for a processor with a very simple architecture and that does all instructions like load, store, arithmetic and logical instructions using a bunch of majority functions. The processor has only one instruction(majority function) in its ISA and breaks down all other instructions into a number of majority instructions depending on what

I am trying to add support for select_cc. In ARM it can be implemented with: mov $dst, $falseVal cmp $a, $b moveq $dst, $trueVal My current strategy is to expand select_cc in two ARM nodes: ARM::SELECT and ARM::CMP. The two nodes would be connected by a flag edge. ARM::CMP would then expand to "cmp $a, $b". This instruction has no results. It only alters the CPSR (current program

Hi, I've read as much as I can regarding the many problems people seem to have with -delete and none of the solutions seems to work for me. I have tried all combinations of using the trailing slash but it seems to have no effect. Does anyone know if -delete can work with -files-from? Here's the code: DIR="/mnt/backup/machine/oracle" FILES=".test_files.files"

I'm working on enhancing TableGen's type checking and it triggered with a problem in CellSPU's specification: XSHWv4i32: (set VECREG:v8i16:$rDest, (sext:v8i16 VECREG:v4i32:$rSrc)) It's complaining that v4i32 is not smaller than v8i16, which is true in the sense of vector bit size, and true in the sense of vector element size. To me, a sign extension from i32 to i16 makes no

Hello all! I'm working on a library with bignum support, and I wanted to try LLVM as an apparently simpler and more portable system to my current design (a Haskell script which spits out mixed C and assembly). Porting the script to use the LLVM bindings instead of the current hack was pretty easy. But I have a few remaining questions: (1) Are bignums exposed to any higher-level

On Jan 9, 2007, at 10:01 AM, Scott Michel wrote: > I was able to resolve my previous question about dealing with custom > loads/stores, and following Chris' suggestion, the IBM Cell SPU > backend > can generate code for "int main(void) { return 0; }" without crashing > llc. There's a lot of work still to be done... like getting frame > offsets correctly

Dear R users, I would like to accumulate objects generated from 'for' loop to a list or array. To illustrate the problem, arbitrary data set and script is shown below, x <- data.frame(a = c(rep("n",3),rep("y",2),rep("n",3),rep("y",2)), b = c(rep("y",2),rep("n",4),rep("y",3),"n"), c =

I was able to resolve my previous question about dealing with custom loads/stores, and following Chris' suggestion, the IBM Cell SPU backend can generate code for "int main(void) { return 0; }" without crashing llc. There's a lot of work still to be done... like getting frame offsets correctly computed and hauling in the raft of intrinsics that the Cell SDK defines. Three quick

I'm trying to define a multiply-accumulate instruction for the LEON processor, a Subtarget of the Sparc target. The documentation for the processor is as follows: === To accelerate DSP algorithms, two multiply&accumulate instructions are implemented: UMAC and SMAC. The UMAC performs an unsigned 16-bit multiply, producing a 32-bit result, and adds the result to a 40-bit accumulator made

I've been looking to see if there's a way to get the instruction below (SMAC) emitted from a higher-level construct, but I'm starting to think this is unrealistic. To do so, I'd have to tie-in two other instructions: Firstly, clearing the ASR18 and Y register somewhere near the start of the method, then copying out the value of these registers somewhere near the end of the method,

On Apr 23, 2007, at 5:06 PM, Chris Lattner wrote: > On Sun, 22 Apr 2007, Christopher Lamb wrote: >> I have a back end which has both scalar and vector registers that >> alias each other. I'm having a problem generating the ISel from >> tablegen that appears only when a vector register class is declared >> to contain integer vectors. At that moment tablegen

Evan Cheng wrote: > On Apr 16, 2009, at 3:17 PM, Greg McGary wrote: > >> Is there some optimizer knob I'm not turning properly? In more complex >> cases, GCC does poorly with two-address operand choices and so bloats >> the code with unnecessary register moves. I have high hopes LLVM >> can do better, so this result for a simple case is bothersome. >>

Digging deeper... 1. Is there a good reason that v2f32 types are excluded from the isFloatingPoint filter? Looks like a bug to me. v2f32 = 22, // 2 x f32 v4f32 = 23, // 4 x f32 <== start ?? v2f64 = 24, // 2 x f64 <== end static inline bool isFloatingPoint(ValueType VT) { return (VT >= f32 && VT <= f128) || (VT