search for: getregclassfor

...ts if the variable/parameter is assigned something else than an MVT. Are there any general objections to replace EVT with MVT in these cases? For example, a quick look at TargetLowering.h give me this list of (member) functions, taking an EVT parameter, that asserts if the argument is not an MVT: getRegClassFor, getRepRegClassFor, getRepRegClassCostFor, setTypeAction, getLoadExtAction, isLoadExtLegal, getTruncStoreAction, isTruncStoreLegal, getIndexedLoadAction, getIndexedStoreAction, getCondCodeAction, getTypeToPromoteTo, addRegisterClass Regards, Patrik Hägglund -------------- next part --------------...

On Mar 21, 2013, at 11:26 AM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > I think in most cases it would be much simpler and safer to specify pattern types directly: > > def : Pat<(and (not i32:$src1), i32:$src2), > (ANDN32rr i32:$src1, i32:$src2)>; > def : Pat<(and (not i64:$src1), i64:$src2), > (ANDN64rr i64:$src1,

...patches are related cleanups in SelectionDAGBuilder. /Patrik Hägglund > git log --stat --reverse origin/master.. commit 8dabe3eb005360347eabb86a2e88c3b6e9098ed5 Author: Patrik Hägglund <patrik.h.hagglund at ericsson.com> Date: Tue Dec 4 10:37:37 2012 +0100 Change TargetLowering::getRegClassFor to take an MVT, instead of EVT. Accordingly, added helper funtions getSimpleValueType (in parallel to getValueType) in SDValue, SDNode, and TargetLowering. include/llvm/CodeGen/FunctionLoweringInfo.h | 2 +- include/llvm/CodeGen/SelectionDAGNodes.h | 11 ++++ include/llvm/...

Hi everyone, I am currently working on a backend for the TriCore architecture. Unfortunately, I have hit an issue with LLVM's internal representation that's giving me a bit of a headache. The problem is that LLVM assumes that a pointer is equivalent to a machine-word sized integer. This implies that all pointer arithmetic takes place in the CPU's general-purpose registers and is done

...sor(MBB_cond); MBB_cond->addSuccessor(MBB_erase); MBB_cond->addSuccessor(MBB_end); MBB_erase->addSuccessor(MBB_cond); MBB_erase->addSuccessor(MBB_end); MachineRegisterInfo &MRI = MBB->getParent()->getRegInfo(); const TargetRegisterClass *AddrRegClass = getRegClassFor(MVT::i64); unsigned regA = MRI.createVirtualRegister(AddrRegClass); unsigned regB = MRI.createVirtualRegister(AddrRegClass); unsigned regC = MRI.createVirtualRegister(AddrRegClass); // Set the indice BuildMI(*MBB, MI, db, TII->get(X86::MOV64rr)).addReg(regA).addReg(X86::RSP)...

...ameter is assigned something else than an MVT. Are there any general objections to replace EVT with MVT in these cases? > > For example, a quick look at TargetLowering.h give me this list of (member) functions, taking an EVT parameter, that asserts if the argument is not an MVT: > > getRegClassFor, getRepRegClassFor, getRepRegClassCostFor, setTypeAction, getLoadExtAction, isLoadExtLegal, getTruncStoreAction, isTruncStoreLegal, getIndexedLoadAction, getIndexedStoreAction, getCondCodeAction, getTypeToPromoteTo, addRegisterClass > Please do. MVT is cheaper than EVT and conceptually clean...

Hello everybody, hi Evan, this patch changes the lowering of arguments for tail call optimized calls. Before arguments that could be overwritten by each other were explicitly lowered to a stack slot, not giving the register allocator a chance to optimize. Now a sequence of copyto/copyfrom virtual registers ensures that arguments are loaded in (virtual) registers before they are lowered to the

...ero:/home/xerxes/llvm-test/fail/CodeGen/notnativelysupported# llvm-as < 2008-02-04-ExtractSubvector.ll | llc llc: /usr/src/openembedded/overo/tmp/work/armv7a-angstrom-linux-gnueabi/llvm2.6-2.6-r0/llvm-2.6/include/llvm/Target/TargetLowering.h:158: llvm::TargetRegisterClass* llvm::TargetLowering::getRegClassFor(llvm::MVT) const: Assertion `RC && "This value type is not natively supported!"' failed. Stack dump: 0. Program arguments: llc 1. Running pass 'ARM Instruction Selection' on function '@main' Aborted 2. lowering sometimes produces unexpected results error htt...

...gt;moveAfter(MBB); // Set the new successors MBB->addSuccessor(MBB_cond); MBB_erase->addSuccessor(MBB_cond); MBB_cond->addSuccessor(MBB_end); MBB_cond->addSuccessor(MBB_erase); MachineRegisterInfo &MRI = MBB->getParent()->getRegInfo(); const TargetRegisterClass *AddrRegClass = getRegClassFor(MVT::i64); unsigned reg = MRI.createVirtualRegister(AddrRegClass); // Set the indice BuildMI(*MBB, MI, db, TII->get(X86::MOV64rr)).addReg(reg).addReg(X86::RSP); // Create the for loop condition BuildMI(*MBB_cond, MBB_cond->end(), db, TII->get(X86::CMP64rr)).addReg(reg).addReg(X86::RBP); Bu...

On 3 December 2012 10:42, Mayur Pandey <mayurthebond at gmail.com> wrote: > So this seems to be the cause of the problem. I guess you're mixing two different problems. First, is the possible lack of conformance with the ABI you state, which I can't comment since I don't know that ABI very well. Second, is the fact that clang is not printing correct debug information (or is

LLVM ARM v6 backend is in fairly good shape. Even the JIT passes nearly the entire llvm test suite. There are some known missing bits: 1. Exception handling 2. Atomic Not sure: 3. Debugging support (should be trivial to hook up if it's not done) Also the thumb backend is not awesome. Its performance is not great. Evan On Apr 1, 2009, at 6:34 AM, Robert Schuster wrote: > Hi, > the

...it-llvm llvm-link basicmath_small.bc rad2deg.bc cubic.bc isqrt.bc -o basicmath.bc llc basicmath.bc -march=mipsel -relocation-model=static -o basicmath The error is: llc: /home/ronaldo/llvm/include/llvm/Target/TargetLowering.h:302: virtual const llvm::TargetRegisterClass* llvm::TargetLoweringBase::getRegClassFor(llvm::MVT) const: Assertion `RC && "This value type is not natively supported!"' failed. 0 llc 0x0000000001557f2d llvm::sys::PrintStackTrace(_IO_FILE*) + 38 1 llc 0x00000000015581aa 2 llc 0x0000000001557b50 3 libpthread.so.0 0x00007f2d54...

...TRI->getAllocatableClass(TII->getRegClass(II, i, TRI, *MF)); That returns GPRBaseRegs for RC, but it then decides to constrain it based on type: if (i < NumResults && TLI->isTypeLegal(Node->getSimpleValueType(i))) { const TargetRegisterClass *VTRC = TLI->getRegClassFor(Node->getSimpleValueType(i)); errs()<<"CVR VTRC: "<<VTRC->getID()<<"\n"; if (RC) VTRC = TRI->getCommonSubClass(RC, VTRC); if (VTRC) RC = VTRC; } VTRC = GPRRegs. Then RC=VTRC makes RC = GPRRegs. the TLI info is fro...

...->getRegClass(II, i, TRI, *MF)); > > That returns GPRBaseRegs for RC, but it then decides to constrain it based > on type: > > if (i < NumResults && TLI->isTypeLegal(Node->getSimpleValueType(i))) { > const TargetRegisterClass *VTRC = > TLI->getRegClassFor(Node->getSimpleValueType(i)); > errs()<<"CVR VTRC: "<<VTRC->getID()<<"\n"; > if (RC) > VTRC = TRI->getCommonSubClass(RC, VTRC); > if (VTRC) > RC = VTRC; > } > > VTRC = GPRRegs. Then RC=VTRC...

..._erase); >> MBB_cond->addSuccessor(MBB_end); >> MBB_erase->addSuccessor(MBB_cond); >> MBB_erase->addSuccessor(MBB_end); >> >> MachineRegisterInfo &MRI = MBB->getParent()->getRegInfo(); >> const TargetRegisterClass *AddrRegClass = getRegClassFor(MVT::i64); >> unsigned regA = MRI.createVirtualRegister(AddrRegClass); >> unsigned regB = MRI.createVirtualRegister(AddrRegClass); >> unsigned regC = MRI.createVirtualRegister(AddrRegClass); >> >> // Set the indice >> BuildMI(*MBB, MI, db, >>...

Currently, instruction selection patterns are defined like this: def : Pat<(and (not GR32:$src1), GR32:$src2), (ANDN32rr GR32:$src1, GR32:$src2)>; def : Pat<(and (not GR64:$src1), GR64:$src2), (ANDN64rr GR64:$src1, GR64:$src2)>; TableGen infers the types of $src1 and $src2 from the specified register classes, and that is the only purpose of the register

Hi, the ARM backend lacks some stuff like support for atomic intrinsics. I learned the hard way (crash). Lately I was told that the ARM backend of LLVM is generally in its early stages of development. I would like to know more about this. Which stuff is missing, known to be unstable and the like. Thanks in advance for taking the time. Regards Robert -------------- next part -------------- A

...*MF)); >> >> That returns GPRBaseRegs for RC, but it then decides to constrain it >> based on type: >> >> if (i < NumResults && TLI->isTypeLegal(Node->getSimpleValueType(i))) { >> const TargetRegisterClass *VTRC = >> TLI->getRegClassFor(Node->getSimpleValueType(i)); >> errs()<<"CVR VTRC: "<<VTRC->getID()<<"\n"; >> if (RC) >> VTRC = TRI->getCommonSubClass(RC, VTRC); >> if (VTRC) >> RC = VTRC; >> } >> >&g...

...;>>> >>>>> Quentin, >>>>> >>>>> I apologize for the spamming here but in getVR (where VReg is >>>>> assigned an RC), it calls: >>>>> >>>>> const TargetRegisterClass *RC = >>>>> TLI->getRegClassFor(Op.getSimpleValueType()); >>>>> VReg = MRI->createVirtualRegister(RC); >>>>> >>>>> My question is why is it using the SimpleValueType to define the >>>>> register class instead of the actual register class defined in the td? What >&g...

Hi Ryan, > On Aug 24, 2015, at 6:49 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > > Quentin, > > I apologize for the spamming here but in getVR (where VReg is assigned an RC), it calls: > > const TargetRegisterClass *RC = TLI->getRegClassFor(Op.getSimpleValueType()); > VReg = MRI->createVirtualRegister(RC); > > My question is why is it using the SimpleValueType to define the register class instead of the actual register class defined in the td? What am I missing here? Right now, the types are bound to register classes. Se...