[swift-dev] [Draft Proposal] Refactor SILParser::parseSILInstruction

Michael Gottesman mgottesman at apple.com
Thu Jan 14 13:27:58 CST 2016


No I mean like this:

1. Add a visitor in SILVisitor.h that just switches on value base.
2. Define a composition class with SILParser:

class SILInstructionParser {
   SILParser *P;

   ValueBase *visitValueBase() { llvm_unreachable("Unimplemented method"); }
   ValueBase *visitSILArgument.
};

...

SILValue SILInstructionParser::visitSILArgument() {
  ...
}

SILValue SILInstructionParser::visitAllocBoxInst() {
   ...
}

Michael

> On Jan 14, 2016, at 9:00 AM, Sergey Bolshedvorsky <sergey at bolshedvorsky.com> wrote:
> 
> Michael,
> 
> The simplest way is to keep the switch statement in the parseSILInstruction method and move all logic into parser routines.  Is it right?
> 
> bool SILParser::parseSILInstruction(SILBasicBlock *BB) {
>   // Header
> 
>   switch (Opcode) {
>   case ValueKind::SILArgument: 
>     return handleValueKindSILArgument(Opcode); 
>     break;
>   case ValueKind::AllocBoxInst: 
>     return handleValueKindAllocBoxInst(Opcode);
>     break;
>   case ValueKind::ApplyInst:
>     return handleValueKindApplyInst(Opcode);
>     break;
>   // ...
>   }
> }
> 
> SILParser::handleValueKindSILArgument(ValueKind Opcode) {
>   // Handle ValueKind::SILArgument case here
> }
> 
> SILParser::handleValueKindAllocBoxInst(ValueKind Opcode) {
>   // Handle ValueKind::AllocBoxInst case here
> }
> 
> SILParser::handleValueKindApplyInst(ValueKind Opcode) {
>   // Handle ValueKind::ApplyInst case here  
> }
> 
> By the way, I’ve noticed that some instructions are getting parsed by parser routines already: parseSILFunctionRef or parseCallInstruction.
> 
> Sergey
> 
> Sent from my iPhone
> 
> On 14 Jan 2016, at 06:00, Michael Gottesman via swift-dev <swift-dev at swift.org <mailto:swift-dev at swift.org>> wrote:
> 
>> 
>>> On Jan 13, 2016, at 9:08 PM, Michael Gottesman via swift-dev <swift-dev at swift.org <mailto:swift-dev at swift.org>> wrote:
>>> 
>>>> 
>>>> On Jan 13, 2016, at 3:35 PM, John McCall via swift-dev <swift-dev at swift.org <mailto:swift-dev at swift.org>> wrote:
>>>> 
>>>>> On Jan 13, 2016, at 3:25 PM, Jordan Rose via swift-dev <swift-dev at swift.org <mailto:swift-dev at swift.org>> wrote:
>>>>> Hey, Sergey. It definitely makes sense to refactor this, but I don't think putting methods on SILInstruction is the way to go about it. There's no reason most clients of SIL need to know anything about parsing; from a separation-of-concerns perspective it belongs in a separate header and very likely a separate component (i.e. not lib/SIL/).
>>>>> 
>>>>> If this were Swift, we could use an extension, but alas. :-)
>>>>> 
>>>>> That said, I'm not a heavy user of SIL, so someone else from the Swift team with more of a stake should comment.
>>>> 
>>>> I agree with you completely.
>>>> 
>>>> Also, the SIL instruction parser does not actually have an instance of an instruction to perform virtual dispatch on.  Nor should we introduce the concept of “wireframe” instructions just for the convenience of the parser. Redundancy between cases here should be addressed with normal redundancy elimination techniques, i.e. macros and templates.
>>> 
>>> The way to do this is to have a visitor parser that takes in a ValueKind and maps it to the parser routine to use.
>> 
>> Let me rephrase. IIRC the way that this code is written is it first deserializes the value kind. Imagine if we had a visitor that was composed with the parser whose visitor methods would perform the relevant parsing.
>> 
>>> 
>>> Michael
>>> 
>>>> 
>>>> John.
>>>> _______________________________________________
>>>> swift-dev mailing list
>>>> swift-dev at swift.org <mailto:swift-dev at swift.org>
>>>> https://lists.swift.org/mailman/listinfo/swift-dev <https://lists.swift.org/mailman/listinfo/swift-dev>
>>> 
>>> _______________________________________________
>>> swift-dev mailing list
>>> swift-dev at swift.org <mailto:swift-dev at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-dev <https://lists.swift.org/mailman/listinfo/swift-dev>
>> 
>> _______________________________________________
>> swift-dev mailing list
>> swift-dev at swift.org <mailto:swift-dev at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-dev <https://lists.swift.org/mailman/listinfo/swift-dev>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20160114/03150449/attachment.html>


More information about the swift-dev mailing list