[llvm] r316479 - MIR: Print the register class or bank in vreg defs

Quentin Colombet via llvm-commits llvm-commits at lists.llvm.org
Tue Oct 24 12:58:02 PDT 2017



> On Oct 24, 2017, at 11:43 AM, Justin Bogner <mail at justinbogner.com> wrote:
> 
> Quentin Colombet <qcolombet at apple.com <mailto:qcolombet at apple.com>> writes:
>>> On Oct 24, 2017, at 11:04 AM, Justin Bogner via llvm-commits
>> <llvm-commits at lists.llvm.org> wrote:
>>> 
>>> Author: bogner
>>> Date: Tue Oct 24 11:04:54 2017
>>> New Revision: 316479
>>> 
>>> URL: http://llvm.org/viewvc/llvm-project?rev=316479&view=rev
>>> Log:
>>> MIR: Print the register class or bank in vreg defs
>>> 
>>> This updates the MIRPrinter to include the regclass when printing
>>> virtual register defs, which is already valid syntax for the
>>> parser. That is, given 64 bit %0 and %1 in a "gpr" regbank,
>>> 
>>> %1(s64) = COPY %0(s64)
>>> 
>>> would now be written as
>>> 
>>> %1:gpr(s64) = COPY %0(s64)
>>> 
>>> While this change alone introduces a bit of redundancy with the
>>> registers block, it allows us to update the tests to be more concise
>>> and understandable and brings us closer to being able to remove the
>>> registers block completely.
>>> 
>>> Note: We generally only print the class in defs, but there is one
>>> exception. If there are uses without any defs whatsoever, we'll print
>>> the class on all uses. I'm not completely convinced this comes up in
>>> meaningful machine IR, but for now the MIRParser and MachineVerifier
>>> both accept that kind of stuff, so we don't want to have a situation
>>> where we can print something we can't parse.
>> 
>> Could we print them on all the uses/defs unless -simplify-mir is used?
>> In other words, I am in favor of less magic as possible in the
>> printer, unless specified otherwise.
> 
> At least in my experiments I found it a lot harder to read and edit the
> assembly in that form. Some of the regclasses have pretty long names,
> and they're usually not terribly interesting in any particular use. I'd
> actually prefer going back to the "only on defs" approach completely,
> but we can't do that unless/until we reject unmarked uses of undef
> vregs.
> 
> Also note that the tests don't use simplify-mir in general, so this
> readability comes up in all of the check lines of all of the tests.

Could we derive a readable, yet complete, form?
When this is not human edited I expect we would want to just print the whole thing. (As in using MachineInstr::dump in a debugger for instance.)

> 
>> The debug machine output does that, though it remains concise because
>> it lists these contraints at the end of instructions and in a
>> condensed way (e.g., regClass1:vregA,vregB; regClass2: vregC).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20171024/171e196e/attachment.html>


More information about the llvm-commits mailing list