[Dwarf-Discuss] Register kinds
Richard.Relph at amd.com
Mon Nov 1 09:02:30 PDT 2010
Thanks for the reply. In the absence of better advice from the group, I've been planning to implement a pretty-straight forward mapping of available registers from all classes to register numbers in DWARF. I don't think adding a layer of indirection is worthwhile at this point.
Well, AMD has some control of the compiler and debugger. And we have more complete control of the DWARF spec for the target architecture.
For those that want to play along, the target architecture for our purposes is the AMD IL for GPUs.
This is an abstraction of the capabilities of AMD GPUs. The IL is itself compiled to machine code by a shader compiler (a version of which is also used for OpenGL and Direct X.) We're defining the debug layer at the IL stage to support multiple different GPU architectures. This complicates things a bit, since the IL spec doesn't actually limit the number of GPRs or their range. The lower-level compiler will do its best to map the IL's GPRs on to available machine registers, but if they don't fit, well... it spills.
Table 5.8 defines the register types. "Components" refers to the number of elements each instance of the register has. Registers with 4 components typically have x, y, z, and w components. The 'temp' register type is the most commonly used register type, but far from the only one.
The source language is OpenCL. The translation system consists of a commercial front-end that we have customized for OpenCL, LLVM for doing optimizations, and our LLVM-based backend for generating AMD IL, which is fed to the final shader compiler to generate machine code.
It's the theoretically unbounded nature of the IL GPRs that is giving me fits at the moment.
From: dwarf-discuss-bounces at lists.dwarfstd.org [mailto:dwarf-discuss-bounces at lists.dwarfstd.org] On Behalf Of David Earlam
Sent: Monday, November 01, 2010 5:56 AM
To: dwarf-discuss at lists.dwarfstd.org
Subject: Re: [Dwarf-Discuss] Register kinds
The register numbers are positive integers.
Registers 0 to 31 encode in a single byte of a DW_OP_reg or DW_OP_breg, beyond that Dwarf uses ULEB128 little-endian representation to compact the encoding, so numbers up to 127 take two bytes and numbers up to 16383 take three bytes with DW_OP_regx or DW_OP_bregx opcodes.
If there's an even distribution of usage you might try spreading the 'kind' field over bits 7..6 and 14..13 and 21..20.
Since you don't state how many kinds you intend, the Dwarf producer can't predict which kinds are most common nor how many references there will be to each register it's hard to think of a scheme to get anywhere near Huffman-like density. Using the register numbers to index into another table shared over all compilation units and sorted by frequency is a tempting extension, especially if that table also provided the mapping to ABI names and bit-sizes of registers. Are you in control of the compiler and debugger?
Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Dwarf-Discuss