similar to: [LLVMdev] PR1350 (Vreg subregs) questions

On Jun 11, 2007, at 6:14 PM, Christopher Lamb wrote: > > What's the best way to get an SDNode through to DAG scheduling > without getting mangled during Lowering/ISel? What do you mean by "mangled"? Please clarify. > > When should subregs be flattened to actual registers: AsmPrinter? > Somewhere in LiveIntervals, during RegAlloc? You mean turning part of a

On Jun 11, 2007, at 7:22 PM, Evan Cheng wrote: > > On Jun 11, 2007, at 6:14 PM, Christopher Lamb wrote: > >> >> What's the best way to get an SDNode through to DAG scheduling >> without getting mangled during Lowering/ISel? > > What do you mean by "mangled"? Please clarify. My mangled I mean the nodes shouldn't be isel'ed into anything else

On Tue, 12 Jun 2007, Christopher Lamb wrote: >> > What's the best way to get an SDNode through to DAG scheduling >> > without getting mangled during Lowering/ISel? >> >> What do you mean by "mangled"? Please clarify. > > My mangled I mean the nodes shouldn't be isel'ed into anything else because > they need to survive through to

On Jun 12, 2007, at 10:53 AM, Chris Lattner wrote: > On Tue, 12 Jun 2007, Christopher Lamb wrote: >>>> What's the best way to get an SDNode through to DAG scheduling >>>> without getting mangled during Lowering/ISel? >>> >>> What do you mean by "mangled"? Please clarify. >> >> My mangled I mean the nodes shouldn't be

On Tue, 12 Jun 2007, Christopher Lamb wrote: >> > > > When should subregs be flattened to actual registers: AsmPrinter? >> > > > Somewhere in LiveIntervals, during RegAlloc? >> >> This should definitely be done during regalloc. > > It seems that LiveIntervals will need to be taught about the new form of > virtual registers. Hrm. I'm

On Jun 13, 2007, at 10:50 AM, Chris Lattner wrote: > On Tue, 12 Jun 2007, Christopher Lamb wrote: >>>>>> When should subregs be flattened to actual registers: >>>>>> AsmPrinter? >>>>>> Somewhere in LiveIntervals, during RegAlloc? >>> >>> This should definitely be done during regalloc. >> >> It seems that

Thanks for the detailed response. On Apr 23, 2007, at 4:22 PM, Chris Lattner wrote: > Right. Evan is currently focusing on getting the late stages of > the code > generator (e.g. livevars) to be able to understand arbitrary machine > instrs in the face of physreg subregs. This lays the groundwork for > handling vreg subregs, but won't solve it directly. Is the work Evan

On Apr 23, 2007, at 4:07 PM, Christopher Lamb wrote: > Thanks for the detailed response. > > On Apr 23, 2007, at 4:22 PM, Chris Lattner wrote: > >> Right. Evan is currently focusing on getting the late stages of >> the code >> generator (e.g. livevars) to be able to understand arbitrary machine >> instrs in the face of physreg subregs. This lays the

On Mon, 23 Apr 2007, Christopher Lamb wrote: >>> The issue I'm having is that there is no extract/insert >>> instruction in the ISA, it's simply based on using subregister >>> operands in subsequent/preliminary instructions. At the pointer of >>> custom lowering register allocation has not yet been done, so I >>> don't have a way to

On Apr 23, 2007, at 8:22 PM, Evan Cheng wrote: > > On Apr 23, 2007, at 4:07 PM, Christopher Lamb wrote: > >> Thanks for the detailed response. >> >> On Apr 23, 2007, at 4:22 PM, Chris Lattner wrote: >> >>> Right. Evan is currently focusing on getting the late stages of >>> the code >>> generator (e.g. livevars) to be able to understand

On Apr 23, 2007, at 1:43 PM, Christopher Lamb wrote: > On Apr 23, 2007, at 1:17 PM, Christopher Lamb wrote: > >> On Apr 23, 2007, at 12:31 PM, Chris Lattner wrote: >> >>> On Mon, 23 Apr 2007, Christopher Lamb wrote: >>>> How can one let the back end know how to insert and extract >>>> elements of >>>> a vector through sub-register

On Apr 24, 2007, at 12:01 PM, Chris Lattner wrote: > Yes, we need those. I think these are the major pieces needed. > These are > all relatively small and independent pieces, so we can tackle these > one at > a time. <snip> > 4. The DAG scheduler pass (which creates machine instrs from dag > nodes) > currently thinks of register operands as simple

Hi Christopher, I can send you what I have for that so far, that works pretty well. Nate On Jun 6, 2007, at 3:06 PM, Christopher Lamb wrote: > > On Apr 24, 2007, at 12:01 PM, Chris Lattner wrote: > >> Yes, we need those. I think these are the major pieces needed. >> These are >> all relatively small and independent pieces, so we can tackle >> these one at

On Tue, 24 Apr 2007, Christopher Lamb wrote: >>> I have other higher priority tasks right now, but I think we'll want >>> to have this in sooner rather than later. If you have any pointers on >>> a good starting point it'd be mighty helpful. If I can get a grasp on >>> it I'll start incremental work in the background. >> >> It's

To say this first: This whole discussion about using virtregs until emit or having growable physregs is hard to argue without actually having experience trying to go either way. Problems when using virtregs throughout the backend until emit time: - The MC layer is using MCPhysReg (which is an uint16_t) and would need retrofitting to support virtregs - VirtRegs are assumed to have a definition,

Hi Susan, > You may find the PBQP allocator implementation useful as a reference > to what's involved in adding a new allocator to LLVM. It's located in > lib/CodeGen/RegAllocPBQP.cpp, with supporting files in the lib/CodeGen/ > PBQP directory. > Yes - as far as working allocators go PBQP is pretty simple. If you're just interested in LLVM API details you can focus on

We had some additional discussion on this. There is a lot of concern generally about post-RA passes which do not expect to have to handle virtual registers; specifically if they unexpectedly start seeing virtual registers, or if they work today but start making assumptions in the future. We discussed considering a mechanism that would require MachineFunctionPasses to "opt-in" and declare

Here are 2 patches, which are independent of each other. The first splits PrologEpilogInserter into 2 parts : http://reviews.llvm.org/D16481 After looking at the code I thought it made more sense for the major split to include whether callee-saved register spills are supported. So for non-virtual targets, virtual registers are not supported and scavenging is optionally supported, and vice versa

I'm running into a problem with subregs during trivial coalescing in the linear scan allocator. Should RALinScan::attemptTrivialCoalescing be allowed to coalesce a COPY that uses a subreg as a destination? I've got the following sequence of code (unfortunately for an out of tree target) that is moving 32 and 64 bit sub-registers around within a 128 bit register. By the time the register

On Mar 15, 2009, at 2:02 PM, Jakob Stoklund Olesen wrote: > Hi, > > I am writing a backend for the Blackfin processor from Analog > Devices. I > just started so I still have a lot to learn about the code > generator. So > far, I can compile test/CodeGen/Generic/BasicInstrs.ll correctly, but > that is about it. > > The Blackfin 32-bit registers divide naturally