similar to: [LLVMdev] apparent mistake in several ports register td file ???

At least or Mips, this line seems extraneous. I removed it and and all consequential uses of that (400 changes to MipsRegisterInfo.td) and make check for mips still works. Am running our full test sequence now. This Mips part of this was copied from the Sparc port. Similar problems in other ports. Seems this has just been copied many times to new ports. On 03/21/2012 02:58 PM, reed kotler

On Mar 21, 2012, at 2:58 PM, reed kotler wrote: > The field Num seems to have no meaning. It is not recognized by the > backend tools. It does not hurt anything but should not be there. > > class ARMReg<bits<4> num, string n, list<Register> subregs = []> : > Register<n> { > field bits<4> Num; > let Namespace = "ARM"; > let

Hi folks, TableGen provides sufficiently rich syntax for expressing target instruction set. Nevertheless, when I wrote the PTX backend, I observed that some redundancy in TableGen can be further eliminated through macro expansion of for-loops. The semantics of a for-loop is expanding the for-loop body, and so it is equivalent to manually unroll the loop (see example #1). I believe the for-loop

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

There's an assert at line 192, lib/CodeGen/RegisterScavenging.cpp that appears to get tripped on targets that don't have subregisters defined: bool SubUsed = false; for (const unsigned *SubRegs = TRI->getSubRegisters(Reg); unsigned SubReg = *SubRegs; ++SubRegs) if (isUsed(SubReg)) { SubUsed = true; break; }

On 6 Dec 2012, at 07:46, 陳韋任 (Wei-Ren Chen) wrote: > The code below in lib/Target/ARM/ARMRegisterInfo.td is where you > should look into, > > // Integer registers > def R0 : ARMReg< 0, "r0">, DwarfRegNum<[0]>; > def R1 : ARMReg< 1, "r1">, DwarfRegNum<[1]>; > > ... That's the easy part. ARM (AArch32) has 16 registers

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

Hi, I want to increase the number of integer registers in the ARM machine. I don't have any idea how/where I can start. Can anybody help me? By the way, what are the following line in the ARMRegisterInfo.td specify: def qsub_0 def qsub_1 .... Thanks Best Regards, A. Yazdanbakhsh

Ugh. Management lobotomy kicked in. Need to RTFC better. On Thu, Feb 25, 2010 at 6:18 PM, Scott Michel <scooter.phd at gmail.com> wrote: > There's an assert at line 192, lib/CodeGen/RegisterScavenging.cpp that > appears to get tripped on targets that don't have subregisters defined: > > bool SubUsed = false; > for (const unsigned *SubRegs =

On Sep 24, 2008, at 10:16 AM, Chris Lattner wrote: > On Sep 24, 2008, at 8:44 AM, Dan Gohman wrote: >>> #2 is conceptually correct. The problem is 128 bit XMM0 is the same >>> register as 32 bit (or 64 bit) XMM0. So it's not possible to define >>> the super-register / sub-register relationship. >> >> I don't understand the problem with subregs

What's the best way to get an SDNode through to DAG scheduling without getting mangled during Lowering/ISel? When should subregs be flattened to actual registers: AsmPrinter? Somewhere in LiveIntervals, during RegAlloc? Is there are common API used to turn vregs into physregs that could be changed to flatten any subregs in a central location? -- Christopher Lamb

Hi Borja, On Jul 10, 2012, at 6:26 PM, Borja Ferrer wrote: > Hello, > > I would like to know if there's a way of setting the callee-saved register list inside getCalleeSavedRegs() to make the PEI pass save/restore only one half of a register pair if the other half is not being used, instead of saving the whole pair. Here is an example of what I try to explain to make things more

Hi Tom, The output: Added VReg_64(explicit) Added VS_32(explicit (VS_32) VReg_64 class-with-subregs: VReg_64) is saying that VS_32 was added because VReg_64 was explicitly specified and that while inspecting VS_32, it noticed that every register in VS_32 was a subregister of a register from VReg_64 using a single common subregister index. I've added some more tracing to my local copy and

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 Sep 24, 2008, at 11:34 AM, Evan Cheng wrote: > > On Sep 24, 2008, at 10:16 AM, Chris Lattner wrote: > >> On Sep 24, 2008, at 8:44 AM, Dan Gohman wrote: >>>> #2 is conceptually correct. The problem is 128 bit XMM0 is the same >>>> register as 32 bit (or 64 bit) XMM0. So it's not possible to define >>>> the super-register / sub-register

On 05/16/2017 11:57 AM, Daniel Sanders wrote: >> If that's right, one possible fix would be to rename some of the subregister indices but that's likely to be quite painful. I'll have a think and see if I can come up with something nicer. > > I haven't been able to come up with a better answer for this, just an alternate choice as to where the complexity is. If we were

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 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 Wed, September 24, 2008 12:10 am, Evan Cheng wrote: > > On Sep 23, 2008, at 7:17 PM, David Greene wrote: > >> Chris Lattner wrote: >>> On Sep 23, 2008, at 11:26 AM, David Greene wrote: >>> >>>> Are there any examples of using tablegen to generate multiple >>>> machine >>>> instructions from a single pattern? Or do these cases