jpy794 / sysy-compiler Goto Github PK

当前的AssignStmt：

struct AssignStmt : Stmt {
    std::string var_name;
    PtrList<Expr> idxs;
    Ptr<Expr> val;
    std::any accept(ASTVisitor &visitor) const override {
        return visitor.visit(*this);
    }
};

作为赋值的左操作数，其中的val使用Ptr<LValExpr>类型更合适，LValExpr的结构体：

struct LValExpr : Expr {
    std::string var_name;
    PtrList<Expr> idxs;
    std::any accept(ASTVisitor &visitor) const override {
        return visitor.visit(*this);
    }
};

这部分是处于语义更贴切的考量，不知道AST那里好不好改。

目标

第一阶段主要完成ir的展开，得到汇编指令的表示：

• 使用虚拟寄存器展开指令：三元码+去除溢出12bit的常量
• 得到足够接近asm的mir，后续只需指派存储位置（寄存器or栈）并维护函数栈帧即可。
• 保留层级关系（function->block->insturctions），为了进行活跃变量分析和一些后续机器相关的优化

与物理寄存器/函数栈帧相关的工作留给第二阶段进行。

设计

简化：先仅支持整形指令

值类型，值类型代表指令中可能出现的操作数类型，具有如下设计：

处理机制：

• ir中的Argument类型：在mir中同样用虚拟寄存器表示，存储在mir::Function中

• 因为寄存器相关而保留的指令：ret、call、

• 跳转指令与fcmp/cmp的合并：ir->mir的阶段，使用额外的栈保存i1类型的指令，遇到br再pop出来

• 防止立即数溢出：imm构造时根据需要生成li指令

与第二阶段适配：

• 虚拟寄存器to物理寄存器/栈帧：使用ud链的设计，在指派寄存器后自动替换虚拟寄存器为物理寄存器，如果是栈帧上的内存则需使用插入额外的load/store指令
• 栈帧的位置指定：不同变量对应的StackObject在第一阶段只能保存大小信息，在第二阶段获得全部信息后才有在栈帧内的偏移信息，在第二阶段构造StackObject到偏移的映射，使用时计算偏移(好像还是很模糊)

问题和可能的解决方案, 以及解决方案可能面临的问题

• 如何防止 bb 的 prebbs / sucbbs 被非法修改
  • 只允许 terminator set_prebbs / sucbbs (friend?), 用户只能通过修改 terminator 指令修改 prebbs / sucbbs; 同时给 bb 添加 optional<Instruction *> terminator 成员, 防止重复设置
    • 如果要在插入 terminator 后删除/替换这条指令该怎么办?
      • a) 不允许删除 terminator, 只允许修改
      • b) 提供专用的 terminator 删除/替换 接口
• set_operand 设为纯虚, 使用虚函数接口防止 inst 的内部状态被破坏 (类型检查, bb 的 prebbs sucbbs 等)
  • 可以在 Instruction 给出一个默认实现
• 是否要把 inst 修改 bb 成员的位置统一起来, 目前插入 ilist 在 bb 的 create_inst 而插入 pre_bbs / suc_bbs 在 inst 的构造函数

以上问题要考虑到未来的具体使用场景

翻译过程中待处理的部分

• 修改ast，提供常量初始化接口
• ast FuncDefGlobal param提供name参数
• ast中AssignStmt是否要将var_name和idxs修改为LValExpr
  这两部分在翻译过程中有相当大的代码重合

• add a virtual method name()
• add a string member to base class, and let derived classes set that member in their own constructors
• let base class dynamic_cast this to derived class, then use switch-case to generate full-name based on base-name generated by derived class

I personally prefer the 2nd one, as it's simple and lets the derived class manage their own name.