FATE backend optimisations #696

2019-12-10T20:58:09+09:00

zxq9 commented

2019-12-10 20:58:09 +09:00

(Migrated from gitlab.com)

Created by: UlfNorell

Notably

Use more than one state register: state records use separate registers for each component.
Unbox singleton records, i.e. record { x : int } is compiled to int.

*Created by: UlfNorell* Notably - Use more than one state register: state records use separate registers for each component. - Unbox singleton records, i.e. `record { x : int }` is compiled to `int`.

zxq9 commented

2019-12-12 17:06:21 +09:00

(Migrated from gitlab.com)

Created by: ThomasArts

Possibly I do not really get all type layers, but {tuple, [A]} in this case would not translate to just A as in scode, but rather keep the FATE tuple notation.

Most likely on purpose.

*Created by: ThomasArts* Possibly I do not really get all type layers, but {tuple, [A]} in this case would not translate to just A as in scode, but rather keep the FATE tuple notation. Most likely on purpose.

zxq9 commented

2019-12-12 17:08:04 +09:00

(Migrated from gitlab.com)

Created by: UlfNorell

No, you're right. That probably needs a case for singletons.

*Created by: UlfNorell* No, you're right. That probably needs a case for singletons.

zxq9 commented

2019-12-12 17:08:18 +09:00

(Migrated from gitlab.com)

Created by: UlfNorell

I'll try to make a test case.

*Created by: UlfNorell* I'll try to make a test case.

zxq9 commented

2019-12-12 17:09:40 +09:00

(Migrated from gitlab.com)

Created by: ThomasArts

I see, the stores are negative numbers and you want to print "store1" for {store, -1}

*Created by: ThomasArts* I see, the stores are negative numbers and you want to print "store1" for `{store, -1}`

zxq9 commented

2019-12-12 17:10:30 +09:00

(Migrated from gitlab.com)

Created by: UlfNorell

No, it's right as it is. The singleton optimisation happens in ast_to_fcode and term_to_fate works on fcode so it's already happened at that point.

*Created by: UlfNorell* No, it's right as it is. The singleton optimisation happens in `ast_to_fcode` and `term_to_fate` works on `fcode` so it's already happened at that point.

zxq9 commented

2019-12-12 17:13:58 +09:00

(Migrated from gitlab.com)

Created by: ThomasArts

Review: Dismissed

You seem to merge this into lima. It's only a compiler thingy, so most likely there is no consensus issue... store was already prepared for this.

*Created by: ThomasArts* **Review:** Dismissed You seem to merge this into `lima`. It's only a compiler thingy, so most likely there is no consensus issue... store was already prepared for this.

zxq9 commented

2019-12-12 17:14:14 +09:00

(Migrated from gitlab.com)

Created by: UlfNorell

No, that's just wrong. Look at the definition of desugar_arg:

desugar_arg(?s(N)) -> {var, -N};
desugar_arg(A) -> A.

*Created by: UlfNorell* No, that's just wrong. Look at the definition of `desugar_arg`: ```erlang desugar_arg(?s(N)) -> {var, -N}; desugar_arg(A) -> A. ```

zxq9 commented

2019-12-12 17:16:30 +09:00

(Migrated from gitlab.com)

Created by: UlfNorell

so most likely there is no consensus issue...

The compiler is not under consensus (aesophia is not even a dependency of the node!), so there is guaranteed to be no consensus issues.

*Created by: UlfNorell* > so most likely there is no consensus issue... The compiler is not under consensus (aesophia is not even a dependency of the node!), so there is guaranteed to be no consensus issues.

zxq9 commented

2019-12-12 17:19:21 +09:00

(Migrated from gitlab.com)

Created by: hanssv

Review: Approved

*Created by: hanssv* **Review:** Approved

zxq9 commented

2019-12-12 17:21:31 +09:00

(Migrated from gitlab.com)

Created by: ThomasArts

Review: Approved

*Created by: ThomasArts* **Review:** Approved

zxq9 commented

2019-12-12 17:22:38 +09:00

(Migrated from gitlab.com)

Merged by: UlfNorell at 2019-12-12 08:22:38 UTC

*Merged by: UlfNorell at 2019-12-12 08:22:38 UTC*

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: QPQ-AG/sophia#696