<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Mar 28, 2013, at 10:03 AM, Jakob Stoklund Olesen <<a href="mailto:stoklund@2pi.dk">stoklund@2pi.dk</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;"><br>On Mar 28, 2013, at 9:42 AM, Ulrich Weigand <<a href="mailto:ulrich.weigand@de.ibm.com">ulrich.weigand@de.ibm.com</a>> wrote:<br><br><blockquote type="cite">The problem intended to be solved by this patch is a peculiarity of the<br>PowerPC assembler format. The general "flow" of the assembler parser on<br>other platforms is that common code will first attempt to classify all<br>instruction operands into categories like "Register of class X",<br>"Immediate", or "Memory address", and *then* go into the instruction table<br>using the opcode and list of operand types to select the matching pattern.<br>This approach assumes that you *can* classify operands by just looking at<br>them in isolation. Unfortunately this is not true on PowerPC, since<br>registers are specified in assembler source simply by their numbers, making<br>them indistinguishable from small immediates. For example, the "3" in "add<br>1, 2, 3" refers to a register while the "3" in "addi 1, 2, 3" refers to the<br>immediate value. This means that basically the whole generic mechanism of<br>classifying operands into register classes does not work, and we need to<br>instead define back-end matchers for all the register classes.<br><br>This would be possible without common code changes by using RegisterOperand<br>classes to specify a ParserMatchClass -- but this means that every instance<br>of a register class in the .td files must be replaced by the corresponding<br>RegisterOperand class, which seems a bit unnecessary to me, and may cause<br>future maintainability hassles. I'd propose to instead allow specifying a<br>ParserMatchClass directly on the RegisterClass itself, which can be done by<br>a minor TableGen change as implemented by this patch.<br></blockquote><br>Actually, I think I would prefer the RegisterOperand solution.<br><br>As we add new targets, it is becoming clearer that a register class is often insufficient for describing register operands, and I think it is healthy to separate the concepts.<br></div></blockquote><div><br></div><div>Yes. The RegisterOperand class is designed for exactly this sort of separation of concerns.</div><div><br></div><div>-Jim</div></div></body></html>