llvm dev - Nov 2013 - [LLVMdev] Modelling M68k registers?

Hi.

I am searching for hints, documents, or a discussion for how to
properly model registers.

As an experiment to learn llvm I am trying to do a M68k backend by
following and modifying the Cpu0 tutorial by Chem Chung-Shu and
Anoushe Jamshidi.

The M68k registers are 32bit and comes in two classes data (d0-d7) and
address (a0-a7). Similar to X86 target a subset of the registers can
be accessed for most ops, lower 8 and 16bit for data regs, and lower
16bit for address regs.

Unlike X86 regs these "subsets" are not named but denoted by the size
of the operation. Compare these two:
  16bit mem to reg: "mov ax, [ebx] -> move.w (a0), d1"
  32bit mem to reg: "mov eax, [ebx] -> move.l (a0), d1"

This makes me think that maybe subregs is not what I should use, but
instead treat it as the byte&word load and store in ARM? Or maybe I
should treat data and address registers differently since writing to
the 'subregs' of a data reg to not change the upper bits, whereas with
address registers all 32bits are signed extended, as in:
   move.l #$12345678, d0
   move.w #$fedc, d0   ; d0==$1234fedc
   move.l #$12345678, a0
   move.w #$fedc, a0   ; a0==$fffffedc

// Fredrik Olsson

On Nov 21, 2013, at 5:04 AM, Fredrik Olsson <peylow at gmail.com> wrote:
> This makes me think that maybe subregs is not what I should use, but
> instead treat it as the byte&word load and store in ARM?
The question to ask yourself here is what you want the register allocator to do
for you.  The reason for modeling the sub-register relationship is if there is
useful bin-packing-like work that you want it to do for you.  If the answer is
no, going the route of a single set of register with aliased named is probably
simpler.
> Or maybe I should treat data and address registers differently 
You almost certainly want to do this for m68k.  A large aspect of getting good
code quality out of it is going to consist of doing a domain-crossing
optimization to keep data in address registers when appropriate for its future
use.  This is not something LLVM will (currently) give you for free, so you want
to design your target description to make it easy for you to do it yourself.

—Owen

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20131121/c26c14ae/attachment.html>