similar to: [LLVMdev] commit r152019 broke architectures with more than 255 registers

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 least > 16 bits wide. I agree. We can limit the number

Hi all, in r152019 (from ctopper), the number of available registers of any type in a machine description is decreased to 256 because it needs to be encoded in uint8_t now. I'm trying to support an experimental embedded architecture with more registers (out of tree), but now that becomes impossible. Anyone knows a solution? Thanks, Bjorn De Sutter Computer Systems Lab Ghent University

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. >>>>> >>>>> I've

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 changed it to uint16_t in r152100. Is that enough for your architecture? On Tue, Mar 6, 2012 at 12:24 AM, Bjorn De Sutter < bjorn.desutter at elis.ugent.be> wrote: > Hi all, > > in r152019 (from ctopper), the number of available registers of any type > in a machine description is decreased to 256 because it needs to be encoded > in uint8_t now. I'm trying to support an

We at Tampere University of technology are using LLVM for high-level optimizations in the compiler for our TTA processor toolkit(TCE) We have a llvm backend which creates our own intermediate code, and our own instruction selector after that (as LLVM's machine code cannot represent the actual machine codes of our processors). This makes our llvm backend quite different from the ordinary

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 defined comparison >>>> >>>> def

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:$op2), "", [(set

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

I tried to generate pattern for 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:

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. >>>>>

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 =

In our architecture (TCE) we have predicate registers, not flags. But our predicates work in a way that in the predicated instruction do not contain only the predicate register, but a predicate register and boolean value pair, the boolean value stating if the instruction is to be executed only if the register is true(normal behavior of predicate regs) or only if the predicate reg is

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))]>; > > > > > But then I end up having the following bug: > >

On Sun, Aug 15, 2010 at 10:04 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk>wrote: > > On Aug 15, 2010, at 5:12 PM, Silvio Ricardo Cordeiro wrote: > > > Is there a way for me to collect statistics about the number of > loads/stores added by the "linearscan" register allocator (just like can be > done with the "local" allocator)? I still haven't

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 between *.a files: find-cycles.pl: libLLVMPTXAsmPrinter.a libLLVMPTXCodeGen.a libLLVMPTXDesc.a llvm[1]: Building llvm-config script. cat:

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?

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 I1Regs:$op3, (setne I32Regs:$op1, I32Regs:$op2))]>;

On 25 Aug 2010, at 02:04, Silvio Ricardo Cordeiro wrote: > On Sun, Aug 15, 2010 at 10:04 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > > On Aug 15, 2010, at 5:12 PM, Silvio Ricardo Cordeiro wrote: > > > Is there a way for me to collect statistics about the number of loads/stores added by the "linearscan" register allocator (just like can be done with

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