[llvm-commits] MachineInstr serializer and parser

[Bin Zeng]

On Jun 1, 2012, at 11:13 AM, Bob Wilson wrote:

> 
> On May 31, 2012, at 9:27 PM, Bin Zeng <bzeng at apple.com> wrote:
> 
>> Hi all,
>> 
>> Thanks for the reviews. I am working on a serializer and parser for MachineInstr's in the backend.
>> The opt driver has a very nice feature that you can serialize IR after a specific pass and, if you
>> want, deserialize it and get an identical copy of the original code before serialization and resume
>> compilation there.  The project I am working on tries to bring that nice feature to the backend so that
>> the MachineInstr's can be serialized after a specific pass and deserialized later and continue codegen
>> there if you want. Since its goal is to help debug passes,  the format will be in human readable yaml 
>> format instead of a binary format.
>> 
>> This patch contains the skeleton of the serializer pass and the parser pass: MachineInstrSerializerPass
>> and MachineInstrParserPass and their command line options: -serialize-mi=pass-arg and
>> -parse-mi=pass-arg where pass-arg is the argument of the pass after which the MachineInstr's will
>> be serialized and parsed respectively. If you have better ideas for their names, please do not hold them
>> to yourself.
> 
> I had earlier suggested naming the command-line options:
> 
>  --stop-after=<pass>
>  --start-after=<pass>
> 
> Those may not be the greatest names but I really dislike the proposed --serialize-mi and --parse-mi names.  Two reasons: (1) From the point of view of someone running llc, these options are controlling which passes get run.  The fact that the machine instructions get (de)serialized is just a prerequisite to support that.  The option names should reflect that.  (2) llc also runs some IR-level passes and I would eventually like these same options to be used to allow stopping/starting after IR-level passes.  Please reconsider the names.
> 

Good point! stop-after and start-after are preferred. 

>> Also, these two passes are MachineFunctionPass's. They can only serialize a MachineFunction at a
>> time so far. To get a snapshot of the whole module after a specific pass, I need to visit the other MachineFunction's.
>> The backend generates code for each MachineFunction at a time. I would appreciate it if you can point
>> me to the right direction.
> 
> I'm not sure offhand what is the right direction, but this isn't it.  The output file header should not be written by a function pass.
> 
> Consider the case of the --start-after option (to use my name).  You don't just want to insert a function pass to parse the machine instructions -- you want it to skip all the prior passes.
> 

Most of the existing passes in the backend are MachineFunctionPass's. The MachineFunctionPass's have two functions doInitialization(M) and doFinalization(M) methods which operate on the Module before and after the pipeline respectively. I will try inserting module level passes after a function level pass in the backend.

>> 
>> Here is the patch. Thanks for reading.
>> -Bin
>> <serialize-parse-mi-0.3.diff>
> 
> One more comment below:
> 
>> Index: include/llvm/InitializePasses.h
>> ===================================================================
>> --- include/llvm/InitializePasses.h	(revision 157693)
>> +++ include/llvm/InitializePasses.h	(working copy)
>> @@ -253,6 +253,8 @@
>> void initializeFinalizeMachineBundlesPass(PassRegistry&);
>> void initializeBBVectorizePass(PassRegistry&);
>> void initializeMachineFunctionPrinterPassPass(PassRegistry&);
>> +void initializeMachineInstrSerializerPassPass(PassRegistry&);
>> +void initializeMachineInstrParserPassPass(PassRegistry&);
>> }
> 
> What's with the "PassPass" names?  I see a bunch of other initialization functions have that naming style, but I don't understand.  At least for your new functions, can't we drop the redundant "Pass" in the name?
> 
> Also, I thought you were going to call these "Reader" and "Writer" instead of "Serializer" and "Parser"?

Sure, no problem. They have been changed to Reader and Writer.