Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve subroutine evaluation code (post frame pointers) #599

Open
jasonpaulos opened this issue Nov 8, 2022 · 0 comments
Open

Improve subroutine evaluation code (post frame pointers) #599

jasonpaulos opened this issue Nov 8, 2022 · 0 comments

Comments

@jasonpaulos
Copy link
Contributor

jasonpaulos commented Nov 8, 2022

This issue deals with code implemented in #584 and #562.

In those PRs, to probe info for has_return and type_of of subroutine declaration, subroutines are evaluated twice: once with ScratchVar arguments, and once with frame pointer arguments. Then during compilation the appropriate version of subroutine evaulator is chosen and used in code generation.

Generally speaking it would be nice to avoid having to evaluate every subroutine twice. Once way of doing that could be with something like a ProxyExpr:

class ProxyExpr(Expr):
    
    def __init__(self, type_of: TealType):
        super().__init__()
        self.representing: Expr | None = None
    
    def resolve_to(self, expr: Expr):
        self.representing = expr
    
    def __teal__(self, options: "CompileOptions"):
        if self.representing is None:
            raise TealInternalError("Not assigned....")
        return self.representing.__teal__(options)

The idea would be to use this as a placeholder before compilation to evaluate the subroutine, then assign the ProxyExpr to its actual value once that's known at compile time.

@jasonpaulos jasonpaulos changed the title Improve subroutine evaluation code Improve subroutine evaluation code (post frame pointers) Nov 8, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants