search for: copyphysreg

Hi, All, I'm trying to build a customized backend and I need to lower the formal arguments like this: There are several specific registers just for storing formal arguments. And also there are several general purpose registers for computation. If there is an instruction which uses parameters, I should first use a move instruction, which moves the value to general purpose register. For

..., it works. > > It would be better to delete those patterns entirely. They'll always > match (if asked) and never give a sane result. Hm, these are no patterns like "def : Pat<..>;". These are patterns inside instructions, and I do have to specify them to use them in copyPhysReg(), don't I? Boris

...EG was defined there, and I directly grabbed the one I need into my calling convention in X86CallingConv.td. However, I got an error while I was trying to codegen a function with my specific calling convention. The error is "Cannot emit physreg copy instruction” which is in llvm::X86InstrInfo::copyPhysReg when it tries to copy the segment register. I think the problem occurs at the beginning of the function when it tries to get the argument from the segment register. Does anyone have any idea on how to fix it or the correct way to use the segment register? Thanks in advance! Best, Chen ----------...

...StackTrace(_IO_FILE*) + 34 1 libLLVM-3.3.so 0x00007f9f68dde9a9 2 libpthread.so.0 0x00007f9f67a07cb0 3 libc.so.6 0x00007f9f67156425 gsignal + 53 4 libc.so.6 0x00007f9f67159b8b abort + 379 5 libLLVM-3.3.so 0x00007f9f68dc1e7c 6 libLLVM-3.3.so 0x00007f9f68fd1832 llvm::X86InstrInfo::copyPhysReg(llvm::MachineBasicBlock&, llvm::MachineBasicBlock::bundle_iterator<llvm::MachineInstr, llvm::ilist_iterator<llvm::MachineInstr> >, llvm::DebugLoc, unsigned int, unsigned int, bool) const + 1762 7 libLLVM-3.3.so 0x00007f9f683afab1 8 libLLVM-3.3.so 0x00007f9f6864c417 llvm::FPPassM...

...Under normal circumstances, i32 is the smallest legal type. Instead, to make this work, would I define a 4-bit subregister of the GPRs to hold the data (or maybe 8 bits, and then also use some CR-pair register class)? Thanks again, Hal > > You don't need pseudo copy instructions, TII::copyPhysReg() is > allowed to insert multiple instructions. > > > > Also, should RA avoid splitting live intervals of accumulators, > > > which creates copy instructions? > > > > The alternative to live range splitting is spilling, which is > > usually worse. > &g...

...libLLVM-3.3.so 0x00007f9f68dde9a9 > 2 libpthread.so.0 0x00007f9f67a07cb0 > 3 libc.so.6 0x00007f9f67156425 gsignal + 53 > 4 libc.so.6 0x00007f9f67159b8b abort + 379 > 5 libLLVM-3.3.so 0x00007f9f68dc1e7c > 6 libLLVM-3.3.so 0x00007f9f68fd1832 > llvm::X86InstrInfo::copyPhysReg(llvm::MachineBasicBlock&, > llvm::MachineBasicBlock::bundle_iterator<llvm::MachineInstr, > llvm::ilist_iterator<llvm::MachineInstr> >, llvm::DebugLoc, unsigned > int, unsigned int, bool) const + 1762 > 7 libLLVM-3.3.so 0x00007f9f683afab1 > 8 libLLVM-3.3.so 0x00007...

...types on register classes are only used by isel, and this register class wouldn't be used before register allocation. Just make it [i32], or even [untyped]. (The type is used to pick a default spill size, so you may need to 'let Size = 4' if you go with untyped). Your implementation in copyPhysReg is the final word on what it means to copy between registers in this class. The register class will not be used automatically without permission from your implementation of getLargestLegalSuperClass. This function should not allow normal GPR registers to be inflated to the GPR+CR super-class becau...

...FG() MachineCopyPropagation: currently has checks (even for release builds) that there are no vregs, and is currently disabled manually for wasm and NVPTX. ExpandPostRAPseudos has 2 parts: LowerSubregToReg expects only physregs and has asserts to ensure it. LowerCopy simply calls TargetInstrInfo::copyPhysReg() to emit the instructions for lowering COPYs (wasm's implementation of copyPhysReg() just handles vregs) and is otherwise agnostic. MachineBlockPlacement doesn't do anything at all to any MachineInstrs itself, but just relies on TargetInstrInfo methods to update the branches. I'll po...

...bit accumulator register. If spilling to multiple registers is unsupported, perhaps I can I define a new register class consisting of paired GPR registers and pseudo copy instructions? Yes, that would work. Look at the ARM GPRPair register class. You don't need pseudo copy instructions, TII::copyPhysReg() is allowed to insert multiple instructions. > > Also, should RA avoid splitting live intervals of accumulators, which creates copy instructions? > > The alternative to live range splitting is spilling, which is usually worse. > > Here I was assuming register allocator will sp...

...classes should be able to handle this. > Cross copies are not allowed (no data path). You mean you can't copy directly from a general purpose register to an address register? That's an unfortunate architectural quirk. You may have to write some interesting and potentially ugly code in copyPhysReg() to handle that. > We use clang 3.0 to produce assembler code. > Because both registers have the same size and type (i16), I don't know > what would be the best solution to distinguish them in order to match > the right instructions. The register classes should take care of thi...

Hi, I'm facing a problem in llvm while porting it to a new target and I'll need some support. We have 2 kind of register, one for general purposes (i.e. arithmetic, comparisons, etc.) and the other for memory addressing. Cross copies are not allowed (no data path). We use clang 3.0 to produce assembler code. Because both registers have the same size and type (i16), I don't know

...libLLVM-3.3.so 0x00007f9f68dde9a9 > 2 libpthread.so.0 0x00007f9f67a07cb0 > 3 libc.so.6 0x00007f9f67156425 gsignal + 53 > 4 libc.so.6 0x00007f9f67159b8b abort + 379 > 5 libLLVM-3.3.so 0x00007f9f68dc1e7c > 6 libLLVM-3.3.so 0x00007f9f68fd1832 > llvm::X86InstrInfo::copyPhysReg(llvm::MachineBasicBlock&, > llvm::MachineBasicBlock::bundle_iterator<llvm::MachineInstr, > llvm::ilist_iterator<llvm::MachineInstr> >, llvm::DebugLoc, unsigned > int, unsigned int, bool) const + 1762 > 7 libLLVM-3.3.so 0x00007f9f683afab1 > 8 libLLVM-3.3.so 0x00007...

...only used by isel, and this > register class wouldn't be used before register allocation. Just > make it [i32], or even [untyped]. (The type is used to pick a > default spill size, so you may need to 'let Size = 4' if you go with > untyped). > > Your implementation in copyPhysReg is the final word on what it means > to copy between registers in this class. > > The register class will not be used automatically without permission > from your implementation of getLargestLegalSuperClass. This function > should not allow normal GPR registers to be inflated to the...

...uld be able to handle this. > >> Cross copies are not allowed (no data path). > You mean you can't copy directly from a general purpose register to an address register? That's an unfortunate architectural quirk. You may have to write some interesting and potentially ugly code in copyPhysReg() to handle that. > Actually, I can't copy them in any way, it's just impossible :-/. >> We use clang 3.0 to produce assembler code. >> Because both registers have the same size and type (i16), I don't know >> what would be the best solution to distinguish them in...

On Mon, Mar 25, 2013 at 4:02 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk>wrote: > > On Mar 25, 2013, at 2:51 PM, Akira Hatanaka <ahatanak at gmail.com> wrote: > > > Yes, it sounds like it will solve the problem. > > > > Using the following example where live ranges of accumulators $vreg_acc0 > and $vreg_acc1 conflict, > > > > MULT

...t;register class inflation". Here's how you enable it: - Define a union register class that contains both CPU64Regs and ACRegs. - Implement TRI::getLargestLegalSuperClass(), and return the new union register class when asked about CPU64Regs or ACRegs (or their sub-classes). - Teach TII::copyPhysReg() to handle the cross-class copies. - Teach TII::storeRegToStackSlot() to constrain the register class to CPU64Regs when asked to spill a virtual register from the union register class. This will use cross-class spilling in most cases, but unfortunately we can't guarantee that an ACRegs virtu...

...currently has checks (even for release builds) > that there are no vregs, and is currently disabled manually for wasm and > NVPTX. > > ExpandPostRAPseudos has 2 parts: LowerSubregToReg expects only physregs > and has asserts to ensure it. > LowerCopy simply calls TargetInstrInfo::copyPhysReg() to emit the > instructions for lowering COPYs (wasm's implementation of copyPhysReg() > just handles vregs) and is otherwise agnostic. > > MachineBlockPlacement doesn't do anything at all to any MachineInstrs > itself, but just relies on TargetInstrInfo methods to update th...

Hi Brian, +1 on what Nemanja said: specifying large register classes is the key. More details here: http://lists.llvm.org/pipermail/llvm-dev/2019-December/137700.html <http://lists.llvm.org/pipermail/llvm-dev/2019-December/137700.html> Cheers, -Quentin > On Sep 9, 2020, at 11:13 AM, Nemanja Ivanovic via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On PowerPC, we

...o handle this. >> >>> Cross copies are not allowed (no data path). >> You mean you can't copy directly from a general purpose register to an address register? That's an unfortunate architectural quirk. You may have to write some interesting and potentially ugly code in copyPhysReg() to handle that. >> > > Actually, I can't copy them in any way, it's just impossible :-/. Do you have load/store instructions for each register class? Worst case you could do a push/pop pair on the stack. It's really, really important that there be a way, even a very exp...

Hi, I would like to start a new porting of GlobalIsel for RISCV. An initial patch about GlobalIsel infrastructure for RISCV was ready now: https://reviews.llvm.org/D65219 There is another porting patch https://reviews.llvm.org/D41653 posted by Leslie Zhai at the end of 2017. I have checked with Leslie about the status of this patch.He has stopped developing it since some questions need be