IssueRaiser

cmd/compile: better const-based optimizations handling in compiler frontend

This issue describes a problem, potential solutions and results collected by a prototype implementation.<br> It will be followed by a go-review CL. ## The current state Some important Go optimization phases happen at the frontend stage where we have annotated AST. Notable examples: 1. Inlining. 1. Escape analysis. 1. Things like short string comparison optimization. While the idea of porting everything to SSA backend sounds exciting: 1. It's not trivial. 1. It's hard to express some things on the SSA level as it is very low-level and sometimes relevant information is erased during the SSA construction. 1. The SSA backend has its own set of little problems. My proposal is to extend frontend part a little bit so there is just a bit more information so some useful optimizations that implemented in frontend can work better. It won't make (potential) transition to SSA harder as the changes are very focused and affect only a few places. ## The problem The problem I want to address in this document is a loss of const nature of values used through local variables. If you use constant value directly, frontend recognizes it. If you're using it through never modified local variable, it does not apply optimizations. I'll describe two things I was investigating, but there can be a few more places where the proposed solution is applicable. ### Problematic case 1: escape analysis for make-slice (See `#24577`) ```go // Can be allocated on stack if "xs" doesn't escape. xs := ma

Posted by quasilyte on Dec 4, 2018, 3:49 PM

Tags

Related issues

Raise real-world problems, find people facing the same issue, and discuss solutions.4,000 issues0 comments

ux (Software)

cmd/compile: better const-based optimizations handling in compiler frontend

quasilyteDec 4, 2018, 3:49 PM

This issue describes a problem, potential solutions and results collected by a prototype implementation.<br> It will be followed by a go-review CL. ## The current state Some important Go optimization phases happen at the frontend stage where we have annotated AST. Notable examples: 1. Inlining. 1. Escape analysis. 1. Things like short string comparison optimization. While the idea of porting everything to SSA backend sounds exciting: 1. It's not trivial. 1. It's hard to express some things on the SSA level as it is very low-level and sometimes relevant information is erased during the SSA construction. 1. The SSA backend has its own set of little problems. My proposal is to extend frontend part a little bit so there is just a bit more information so some useful optimizations that implemented in frontend can work better. It won't make (potential) transition to SSA harder as the changes are very focused and affect only a few places. ## The problem The problem I want to address in this document is a loss of const nature of values used through local variables. If you use constant value directly, frontend recognizes it. If you're using it through never modified local variable, it does not apply optimizations. I'll describe two things I was investigating, but there can be a few more places where the proposed solution is applicable. ### Problematic case 1: escape analysis for make-slice (See `#24577`) ```go // Can be allocated on stack if "xs" doesn't escape. xs := ma

Comments (0)

No comments yet. Start the discussion.

Comment on this issue