search for: kultala

On 1 Oct 2010, at 13:35, Bill Wendling wrote: > On Sep 30, 2010, at 2:13 AM, Heikki Kultala wrote: > >> Bill Wendling wrote: >>> On Sep 29, 2010, at 12:36 AM, Heikki Kultala wrote: >>> >>>> On 29 Sep 2010, at 06:25, Heikki Kultala wrote: >>>> >>>>> Our architecture has 1-bit boolean predicate registers. >>>>&...

Bill Wendling wrote: > On Sep 30, 2010, at 2:13 AM, Heikki Kultala wrote: > >> Bill Wendling wrote: >>> On Sep 29, 2010, at 12:36 AM, Heikki Kultala wrote: >>> >>>> On 29 Sep 2010, at 06:25, Heikki Kultala wrote: >>>> >>>>> Our architecture has 1-bit boolean predicate registers. >>>>&gt...

Our architecture(TCE) can have LOTS of registers. It seems r152019 changed some register bookkeeping data structures to 8-bit. This broke support for architectures with >255 registers. Please revert this change or make those register-related values at least 16 bits wide.

Please test if r115571 has fixed it. Evan On Oct 4, 2010, at 5:00 AM, Heikki Kultala wrote: > Bill Wendling wrote: >> On Sep 30, 2010, at 2:13 AM, Heikki Kultala wrote: >> >>> Bill Wendling wrote: >>>> On Sep 29, 2010, at 12:36 AM, Heikki Kultala wrote: >>>> >>>>> On 29 Sep 2010, at 06:25, Heikki Kultala wrote: >&...

On Sep 30, 2010, at 2:13 AM, Heikki Kultala wrote: > Bill Wendling wrote: >> On Sep 29, 2010, at 12:36 AM, Heikki Kultala wrote: >> >>> On 29 Sep 2010, at 06:25, Heikki Kultala wrote: >>> >>>> Our architecture has 1-bit boolean predicate registers. >>>> >>>> I've de...

On Mar 5, 2012, at 5:39 AM, Heikki Kultala wrote: > Our architecture(TCE) can have LOTS of registers. > > It seems r152019 changed some register bookkeeping data structures to > 8-bit. This broke support for architectures with >255 registers. > > Please revert this change or make those register-related values at lea...

Bill Wendling wrote: > On Sep 29, 2010, at 12:36 AM, Heikki Kultala wrote: > >> On 29 Sep 2010, at 06:25, Heikki Kultala wrote: >> >>> Our architecture has 1-bit boolean predicate registers. >>> >>> I've defined comparison >>> >>> def NErrb : InstTCE<(outs I1Regs:$op3), (ins I32Regs:$op1,I32Regs:$o...

Our architecture has 1-bit boolean predicate registers. I've defined comparison def NErrb : InstTCE<(outs I1Regs:$op3), (ins I32Regs:$op1,I32Regs:$op2), "", [(set I1Regs:$op3, (setne I32Regs:$op1, I32Regs:$op2))]>; But then I end up having the following bug: Code %0 = zext i8 %data to i32 %1 = zext i16 %crc to i32 %2 = xor i32 %1, %0 %3 = and i32 %2, 1 %4 =

On 29 Sep 2010, at 06:25, Heikki Kultala wrote: > Our architecture has 1-bit boolean predicate registers. > > I've defined comparison > > > def NErrb : InstTCE<(outs I1Regs:$op3), (ins I32Regs:$op1,I32Regs:$op2), "", [(set I1Regs:$op3, (setne I32Regs:$op1, I32Regs:$op2))]>; > > > >...

On Sep 29, 2010, at 12:36 AM, Heikki Kultala wrote: > On 29 Sep 2010, at 06:25, Heikki Kultala wrote: > >> Our architecture has 1-bit boolean predicate registers. >> >> I've defined comparison >> >> def NErrb : InstTCE<(outs I1Regs:$op3), (ins I32Regs:$op1,I32Regs:$op2), "", [(set I1Reg...

It seems some optimization pass converts some address computation add's into or's when it knows it's allowed due correct alignment. How do I turn this off keep the address calculations as adds?

...omething else, perhaps we can add the address space as another field to the MachineMemOperand. If the Value* gets cleared, at least that would still be available, and I cannot imagine any transformation that would cause the pointer address space to change. On Tue, Dec 11, 2012 at 2:52 PM, Heikki Kultala <hkultala at cs.tut.fi> wrote: > > On 11 Dec 2012, at 21:00, Justin Holewinski wrote: > > > I want to get some clarification on the exact semantics of the > MachineMemOperand attached to memory-touching instructions. From what I > understand, a MemSDNode has an associat...

On Feb 17, 2010, at 3:15 AM, Heikki Kultala wrote: > LLVM 2.7 is dropping rtti on default build, which is a problem to us. > We are using Boost libraries on many places in our code, and Boost has > some heavy usage of type info tricks, which cannot be compiled without > rtti, so we have to keep rtti on for our code. > >...

On 5 Oct 2010, at 01:48, Evan Cheng wrote: > Please test if r115571 has fixed it. thanks a lot, I tested and 115571 fixed this. can it still be merged into 2.8 before release?

LLVM code base seems to be full of base/interface classes, which have methods like virtual SDValue LowerCall(SDValue Chain, SDValue Callee, CallingConv::ID CallConv, bool isVarArg, bool &isTailCall, const SmallVectorImpl<ISD::OutputArg> &Outs, const SmallVectorImpl<SDValue> &OutVals, const

Our TCE backend (which is not in the official llvm repo) benefits greatly from information that which memory load/store is a spill generated by register allocation. These spill memory operation can never alias with other memory operations, and our own instruction scheduler can optimize much better with better alias information. I have created a code which adds marking these spill

On Thu, Sep 29, 2011 at 3:06 AM, Heikki Kultala <hkultala at iki.fi> wrote: > > > make[1]: Entering directory > `/home/hkultala26/src/llvm-trunk/llvm/tools/llvm-config' > llvm[1]: Regenerating LibDeps.txt.tmp > llvm[1]: Checking for cyclic dependencies between LLVM libraries. > find-cycles.pl: Circular dependency...

I'm having some troubles implementing vector support to our custom backend It seems that llvm cannot emulate shuffle with extracts, inserts and builds? I've enabled vector registers with addRegisterClass(MVT::v2i32, TCE::V2I32RegsRegisterClass); addRegisterClass(MVT::v2f32, TCE::V2F32RegsRegisterClass); and created patterns for most vector instructions, including insert, extract and

I am a bit confused how the rematerialization works. It seems currently in our backend we get lots of code where some stack offset address is calculated, but this address is then spilled to stack, and loaded from stack later. This does not make sense, it would be better to just recalculate the address later, ie rematerialize the original stack offset calculation. But marking some instruction

...instruction which transports floating point immediate to a floating point register. def MOVF32fk : InstTCE<(outs F32Regs:$dst), (ins f32imm:$val), "$val -> $dst;", [(set F32Regs:$dst, (f32 imm:$val))]>; This causes an type contradiction: /home/hkultala26/src/devel/tce/src/applibs/LLVMBackend/plugin//TCEInstrInfo.td:109:1: error: In MOVF32fk: Type inference contradiction found, 'f32' needs to be integer def MOVF32fk : InstTCE<(outs F32Regs:$dst), (ins f32imm:$val), why? Why does llvm assume floating point immediate needs to be inte...