similar to: [LLVMdev] Registers and Register Units

On Apr 19, 2013, at 7:18 AM, <dag at cray.com> wrote: > Jakob Stoklund Olesen <stoklund at 2pi.dk> writes: > >>> A MachineOperand has both a getReg() and a getSubReg() interface. >>> For a physical register operand, is getReg() guaranteed to be the >>> "most super" register with getSubReg() providing the specific >>> subregister

Hi, I'm trying to complete the lowering for a new microcontroller. I'm using LLVM 3.8. For now this lowering crashes on 'Store' node, which is actually not yet defined. I've tried to map the ISel 'Store' node to architecture specific instructions. I've define the following semantic to my architecture specific instructions: def MOVSUTO_SU_rr :

Hi, It seems to me that the TwoAddressInstructionPass::runOnMachineFunction method has some problems when the tied destination register has a subReg. The two changes below improves the situation for me but I'm all new to this so I'm not sure how it's supposed to work. I'm running on 2.9. Any comments? @@ -1172,12 +1172,20 @@ bool

Hi, Assume I define registers R0...R15 and two register classes RegA and RegB. RegA contains R0 to R7 while RegB contains R0 to R15. Then I check the machine instruction, it seems that in some cases, the %vreg0 belongs to RegB; in other cases %vreg1 belongs to RegA_RegB. Can you tell me how TableGen decides which is which? At first, I guess &verg0 will be assigned by R8 to R15 only so that

> > Thank you Chris. I will try to implement the TwoAddress pass to run on > > machine code. Why it has not been originally implemented to run on > > machine code? > > I'm not sure what you mean. It definitely does run on machine code. I was thinking that it only transformed instructions with virtual registers because of this code in the TwoAddressInstructionPass.cpp:

This sounds like llvm.org/pr13320. On 17 September 2013 18:20, Bader, Aleksey A <aleksey.a.bader at intel.com> wrote: > Hi all. > > > > I’m looking for an advice on how to deal with inefficient code generation > for Intel Nehalem/Westmere architecture on 64-bit platform for the attached > test.cpp (LLVM IR is in test.cpp.ll). > > The inner loop has 11 iterations

LLVM can model some quite complicated register banks now, and we even use registers to model some encoding constraints. For example, a few ARM instructions like strexd have two register operands that must be an aligned pair of consecutive GPR registers (like r0, r1). This constraint is modeled with the GPRPair register class containing R0_R1, R2_R3, ... pseudo-registers. Sometimes ISAs also

Hi all. I'm looking for an advice on how to deal with inefficient code generation for Intel Nehalem/Westmere architecture on 64-bit platform for the attached test.cpp (LLVM IR is in test.cpp.ll). The inner loop has 11 iterations and eventually unrolled. Test.lea.s is the assembly code of the outer loop. It simply has 11 loads, 11 FP add, 11 FP mull, 1 FP store and lea+mov for index

The two address pass is only concerned about register pressure. It sounds like it should be taught about profitability. In cases where profitability can only be determined with something machinetracemetric then it probably should live it to more sophisticated pass like regalloc. In this case, we probably need a profitability target hook which knows about lea. We should also consider disabling

Hi, I'm having trouble using virtual register in the X86 backend. I implemented a new intrinsic and I use a custom inserter. The goal of the intrinsic is to set the content of the stack to zero at the end of each function. Here is my code: MachineBasicBlock * X86TargetLowering::EmitBURNSTACKWithCustomInserter( MachineInstr *MI, MachineBasicBlock

Jakob, I've implemented a patch that reworks the MCRegAliasIterator to dynamically compute the register aliases. The size reduction in the RegDiffLists are rather dramatic. Here are a few size differences for MCTargetDesc.o files (before and after) in bytes: R600 - 36160B - 11184B - 69% reduction ARM - 28480B - 8368B - 71% reduction Mips - 816B - 576B - 29% reduction One side effect of

On Oct 2, 2013, at 11:48 PM, Evan Cheng <evan.cheng at apple.com> wrote: > The two address pass is only concerned about register pressure. It sounds like it should be taught about profitability. In cases where profitability can only be determined with something machinetracemetric then it probably should live it to more sophisticated pass like regalloc. > > In this case, we

On Mon, 26 Jun 2006, Fernando Magno Quintao Pereira wrote: >>> Thank you Chris. I will try to implement the TwoAddress pass to run on >>> machine code. Why it has not been originally implemented to run on >>> machine code? >> >> I'm not sure what you mean. It definitely does run on machine code. > > I was thinking that it only transformed

Hi, Thx for your help... Here is the IR code: ; ModuleID = 'foo_bar.c' target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128" target triple = "x86_64-unknown-linux-gnu" @.str = private unnamed_addr constant [6 x i8] c"MAIN\0A\00", align 1 ; Function Attrs: nounwind uwtable define i32 @main(i32 %argc, i8** %argv) #0 { entry: %retval = alloca i32,

>-----Original Message----- >From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of >Sanjoy Das via llvm-dev >Sent: Thursday, December 03, 2015 11:16 PM >To: Quentin Colombet <qcolombet at apple.com> >Cc: llvm-dev at lists.llvm.org >Subject: Re: [llvm-dev] analyzePhysReg question > >I think this is related to PR25033:

Ø It would be good to check that this maps correctly onto computeRegisterLiveness: there's a bug in analyzePhysReg and I think other parts of the code base are slightly wrong or will become slightly wrong as well :-( Yes, I agree. I will also have to look into all other users of analyzePhysReg as well. There are surprisingly few users of either computeRegisterLiveness or analyzePhysReg.

I discovered I needed: Index: lib/CodeGen/TwoAddressInstructionPass.cpp =================================================================== --- lib/CodeGen/TwoAddressInstructionPass.cpp (revision 71041) +++ lib/CodeGen/TwoAddressInstructionPass.cpp (working copy) @@ -935,6 +935,7 @@ ++NumReMats; } else { bool Emitted = TII->copyRegToReg(*mbbi, mi, regA,

Hello, Im back trying to finish my backend to a simple RISC cpu SABRE now that most of the tedious process of examining undergraduate students is out of the way. I have managed to describe the registers and the instructions in the architecture and have added support for 32 bit immediates (thanks to Christopher Lamb) as the instruction set only supports 17 bit immediates directly. Could

Jakob Stoklund Olesen <stoklund at 2pi.dk> writes: >> A MachineOperand has both a getReg() and a getSubReg() interface. >> For a physical register operand, is getReg() guaranteed to be the >> "most super" register with getSubReg() providing the specific >> subregister information for the operand? If so then for my current >> purposes it seems I

Hi all, Sorry for arriving late to the party. First, some context: vld1 is not the same as a pointer dereference. The alignment requirements are different (which I saw you hacked around in your testcase using attribute((aligned(4))) ), and in big endian environments they do totally different things (VLD1 does element-wise byteswapping and pointer dereferences byteswaps the entire 128-bit