similar to: analyzePhysReg question

>-----Original Message----- >From: Quentin Colombet [mailto:qcolombet at apple.com] >Sent: Thursday, December 03, 2015 4:43 PM >To: Smith, Kevin B <kevin.b.smith at intel.com> >Cc: llvm-dev at lists.llvm.org >Subject: Re: [llvm-dev] analyzePhysReg question > > >> On Dec 3, 2015, at 4:35 PM, Smith, Kevin B via llvm-dev <llvm- >dev at lists.llvm.org>

> On Dec 3, 2015, at 5:36 PM, Quentin Colombet via llvm-dev <llvm-dev at lists.llvm.org> wrote: > >> >> On Dec 3, 2015, at 5:11 PM, Smith, Kevin B <kevin.b.smith at intel.com <mailto:kevin.b.smith at intel.com>> wrote: >> >> >> >>> -----Original Message----- >>> From: Quentin Colombet [mailto:qcolombet at apple.com

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

Dear LLVM guys, I am coding a liveness analysis algorithm, and I found this comment on LiveVariables.cpp: Line 00195 - http://llvm.org/doxygen/LiveVariables_8cpp-source.html : // PhysRegInfo - Keep track of which instruction was the last use of a // physical register. This is a purely local property, because all physical // register references as presumed dead across basic blocks.

Hi all, Sorry to bother those not interested in this problem. I have a problem while I want to reuse the liveness information after register allocation. When I use the livein_begin() from MachineBasicBlock to get the live-in registers after register alloction. I found that the liveness information is sometime incorrect. For example, some registers should be live-in to the machine basic block as

Hi everyone, I am puzzled by several instruction defines in MSP430. 1 def MOV16rr : Pseudo<(outs GR16:$dst), (ins GR16:$src), "mov.w\t{$src, $dst}", [ ]>; Because it's an empty dag pattern[ ], by what does instuction selector select intruction 'MOV16rr'? 2 let canFoldAsLoad = 1, isReMaterializable = 1, mayHaveSideEffects =

While migrating my codebase from llvm-2.6 to llvm-2.7, I found a different behaviour in the register allocation. I have been able to reproduce it using the msp430 backend, with the 2.7 release as well as the svn head. For the msp430, the first four parameters of a function are passed thru registers. What I observe is that if those parameters are not used inside the function, those registers can

Oops. Forgot the mailing list in the reply. -- Arnaud de Grandmaison ________________________________________ From: Arnaud Allard de Grandmaison Sent: Thursday, June 03, 2010 9:57 PM To: Jakob Stoklund Olesen Subject: RE: [LLVMdev] Unused argument registers can not be reused ? I have finally been able to make some progress : the bug has been introduced/revealed by svn commit #95493, which enabled

Hi, 1. This instruction is not selected automatically by the instruction selector. The instruction combine / select stages insert registercopies, and they are expanded later on by the copyRegToReg() function provided by the MSP430InstrInfo to this MOV16rr. 2. ReMaterializable means there is no need to find a way to preserve the value in a register : the instruction can be just be reissued

Hi, I'm trying to implement a new backend for an embedded CISC processor. Therefore I thought that it makes sense to take X86 target as a basis, to save some time. But when I look into the X86InstrInfo.td, I have a very strong feeling that it is one of the most complex instruction set descriptions compared to other targets. I can imagine that this is due to the complexity of X86's

On Sun, 1 Oct 2006, Roman Levenstein wrote: > I'm trying to implement a new backend for an embedded CISC processor. > Therefore I thought that it makes sense to take X86 target as a basis, > to save some time. Ok. Note that the X86 backend is one of the most complex though, because it supports several subtargets and ABIs, which makes it more complex than some other targets. >

Hi everyone I'm hitting an assertion in PHIElimination.cpp:375. "Terminator instructions cannot use virtual registers unless" "they are the first terminator in a block!" I was looking at the code around that location a bit and have not found a reason why this assertion has to hold, except for a comment: // In our final twist, we have to decide which instruction

Hi Chris, Thanks a lot for your answer! Chris Lattner wrote: >> 1. Why does X86 instruction set description provide different >> descriptions for the same instructions, which differ only in the size >> of operands? >> E.g. >> >> def MOV8rm : I<0x8A, MRMSrcMem, (ops GR8 :$dst, i8mem :$src), >> "mov{b} {$src, $dst|$dst, $src}",