[aarch64-port-dev ] Notations and reliability

[Andrew Dinn]

On 28/03/17 10:16, Andrew Haley wrote:
> We've come a cropper a couple of times because of poorly-chosen
> notations.  Several times we've had a confusion between iRegI and
> iRegINoSp, which causes very obscure crashes.  Also, a little while
> ago I found several bugs (all mine) caused by getting mixed up between
> e.g. strw and str.
> 
> I now believe that I made a mistake when I assumed that Xwords
> (i.e. 64 bits) were in some way the "default" size on AArch64 and
> omitted the X suffix on them.  In hindsight, it is much better for
> every operation to have a size associated with it, so the programmer
> would be forced to choose which one to use, and state it explicitly.
> This is how the "standard" assembly language works, and it is better
> than what we do.
> 
> [Interestingly, the Oracle-authored AArch64 port made exactly the
> same (poor, IMO) choice.  Perhaps programmers' brains are isomorphic.]
> 
> With regard to register classes, GCC uses "GENERAL_REGS" as the name
> of the register class that can be allocated as a general-purpose
> operands, with "ALL_REGS" for everything.  It would be better we did
> something similar.

We do actually have quite clear names for the register /classes/ much as
per x86. The names giving rise to the confusion are those employed in
the /operand/ definitions. Note that unlike the register classes these
all come in multiple flavours -- I, L,P, N etc -- according to the type
of value that will be found in the register. I don't think our names are
actually that much more opaque than x86. For example, it has

  rRegI
  rRegP
  any_RegP
  no_rax_rdx_RegL
  ...

  It's not actually very clear what is the difference between rRegP and
any_RegP until you refer back to the register classes.

  The last name cited above makes it plain that you cannot match 2
specific registers but it is not really clear why. Also, if we used
something like that in AArch64 where there are more 'special' registers
which we might potentially want to exclude then it wouldn't really scale.

I believe that we actually only have 3 operand names that are
potentially subject to confusion. There are these two operand groups (by
groups I mean they exist in multiple flavours of X, one for each of the
available value type labels, I, L, P etc)

  iRegX
  iRegXNoSp

There is also this single operand

  iRegIorL2I

iRegX matches any register holding a value of type X from R0 to R31.
iRegXNoSp matches any non-special register holding a value of type X
from R0 to R26 i.e. it omits the special registers R27 to R31 that are
dedicated to storing VM/frame state i.e. rheapbase, rthread, fp, lr and sp.

We could perhaps relabel these to

  iRegXAll and iRegXGen

or some other name of choice. However, I am not sure that it is any more
apparent to anyone who doesn't already understand what is going on that
an All (or, say, Any) register is any more or less general than a Gen
register. I think the real problem here is that those of us who do know
what is going on did not adequately review the proposed changes which
mistakenly employed the wrong register types.

Will this change help us? I am not really convinced. With any of these
current or possible future names it is very apparent what registers any
given operand will select for matching or assignment if i) you know/look
up the register classes they are derived from and ii) you understand how
that definition gets used by the matcher/register allocator.

The 3rd operand iRegIorL2I is specific to AArch64 rules. It allows a
rule requiring a 32 bit integer (I) input to match and directly consume
a value generated as a 64 bit integer (L) output by some other rule
without the need for an intervening L2I to be employed. Without it we
would need to duplicate all rules employing iRegIorL2I inputs to handle
both iRegI and iRegL case handling.

I don't think this is a particularly bad name and would not really want
to change it. More importantly, as before, I don't think any name is
going to help someone who doesn't already understand what is going
recognise what this rule does and know how to use this operand.

If we do anything I would prefer just to expand iRegXNoSp to
iRegXNoSpecial which avoids the potential ambiguous reading that it
means no Stack Pointer. That may invite 'lay' readers to wonder what
NoSpecial means and perhaps, in consequence, to consider what they are
doing and ask for advice before trying to write new rules.

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander