This is an archive of the discontinued LLVM Phabricator instance.

[ARM] Mark a bunch of .td Operands with type _MEMORY.
ClosedPublic

Authored by ab on Mar 25 2015, 3:39 PM.

Details

Summary

This adds a bunch of OPERAND_MEMORY OperandTypes around the memory operands (addrmode & friends).

I'm pretty sure this can't affect anything in-tree, but not 100%, hence this thread. This also makes this all pretty much untestable. The OperandType users are mostly disassemblers and similar tools; more information is helpful for those.

Some of the PC-relative things, I'm on the fence (e.g. addrmodepc, t2adrlabel, t_adrlabel, and the various *ld*pcrel*). OPERAND_PCREL sounds better, but in practice, I know some OperandType users interpret "PCREL" as labels and other code-related pointers, so OPERAND_MEMORY is more suitable, really. Basically, the names are a tad misleading.

Thanks!
-Ahmed

Diff Detail

Event Timeline

ab updated this revision to Diff 22683.Mar 25 2015, 3:39 PM
ab retitled this revision from to [ARM] Mark a bunch of .td Operands with type _MEMORY..
ab updated this object.
ab edited the test plan for this revision. (Show Details)
ab added a reviewer: rengolin.
ab added subscribers: Unknown Object (MLST), grosbach.
qcolombet added inline comments.
lib/Target/ARM/ARMInstrInfo.td
837

What is the rational behind the non-consistent uses of MemOperand and let OperandType = “OPERAND_MEMORY"?

ab added inline comments.Apr 3 2015, 2:37 PM
lib/Target/ARM/ARMInstrInfo.td
837

I tried to distinguish operands that are actual pointers (e.g., ldst_so_reg above), to operands that are merely components of a pointer (postidx_imm8, postidx_reg, etc..), and aren't pointers by themselves.

For instance, grepping around for postidx_reg, it's used as an index added to addr_offset_none, which is a MemOperand.

This is a very weak argument though, and writing it now, I'm not even convinced anymore. Should I stick with MemOperand?

qcolombet added inline comments.Apr 3 2015, 2:59 PM
lib/Target/ARM/ARMInstrInfo.td
837

I guess it depends how you use them afterwards :).

Anyhow, whatever you choose, update the comment on the MemOperand class to explain when (not) to use it.

ab updated this revision to Diff 23350.Apr 7 2015, 10:23 AM
  • Switch postidx_ from explicit OPERAND_MEMORY to MemOperand; elaborate a bit in the comment.
qcolombet accepted this revision.Apr 7 2015, 10:48 AM
qcolombet added a reviewer: qcolombet.

LGTM.

Thanks,
-Quentin

This revision is now accepted and ready to land.Apr 7 2015, 10:48 AM
This revision was automatically updated to reflect the committed changes.