cleanup backend memory accessors

[Nathan Froyd]

There's quite a bit of code duplication in several places in the backends:

- Between array accessors and SAP accessors;

- Between various accessors for primitive types.

There's some effort to address these concerns with things like WORD-INDEX-REF, SLOT-SET, CELL-SET, and DEFINE-FULL-REFFER, but we still have a lot of very similar VOPs running about--especially with things like DEFINE-FULL-REFFER. This costs us core size as well as complicating future IR2 optimizers that want to look at memory references etc., since we don't have a uniform set of primitives.

One way to address this would be to introduce something like a MEMORY-REF family of VOPs:

(MEMORY-REF/TYPE BASE INDEX OFFSET LOWTAG)

and similarly for MEMORY-SET. OFFSET and LOWTAG would be constants; OFFSET would be in units of the TYPE being referenced, similar to how the -OFFSET constants generated by primitive type definition work. We could have separate /TYPE variants for all sizes of data (similar to how array accessors are done) or we could have separate /TYPE variants for the storage class of the result datum (this would require adding another parameter describing the size of the result datum). The latter is probably more efficient size-of-the-compiler wise, but will probably require unneeded :TEMPORARY variables in the VOPs, which is not so great for performance.

Along with this, there would need to be ir2-convert optimizers for AREF, SAP-REF-X, etc. to expand into MEMORY-{REF,SET} as appropriate.

I don't have time to work on this right now--it's a big project to modify all the backends, but it's not particularly difficult conceptually.

[Nathan Froyd (froydnj)]

Also, bonus points if the eventual design can eliminate the raw slot accessors for structures in favor of this framework.

[Nikodemus Siivola (nikodemus)]

Marking as triaged -- which is the new "confirmed by someone on sbcl-hackers".

[Nathan Froyd (froydnj)]

Nikodemus's status change also reminded me that this is harder than it looks because of representation selection issues. If you have

 (memory-ref X Y ...)

where X is the object (SAP, array, etc.) you're ref'ing off of, what should the SC of X be specified as in the VOP? You don't want to make it DESCRIPTOR-REG, because that makes things difficult for SAPs. I don't think saying * for the SC is right, either; I think you will also lose if you attempt to say (DESCRIPTOR-REG SAP-REG). There are also :ARG-TYPES issues lurking here.

I think the Right Thing is to rewrite the VOP machinery so that constraints are not specified per-argument/per-result, but as a set of alternatives encompassing all the arguments and results. So instead of saying something like:

  (:args (x :sc (descriptor-reg control-stack)) (y :sc (descriptor-reg control-stack)))
  (:results (r :sc (descriptor-reg control-stack)))

and sorting out what's legal and what's not in :LOAD-IF and so forth, you say something like:

  (:args x y)
  (:results r)
  ; specified as ((X Y) R)
  (:sc-alternatives ((descriptor-reg descriptor-reg) descriptor-reg) ((descriptor-reg control-stack) descriptor-reg) ...)

That's not a complete design, as you need to munge :ARG-TYPES and :RESULT-TYPES in there somewhere. But that's the general idea.

[Douglas Katzman (dougk)]

Random ideas about how to do a whole swath of vops better don't belong in the issue tracker.