WASM: Initial support for complex numbers #1527

ubaidsk · 2023-02-15T21:54:28Z

This PR adds support for complex numbers and operations on them in the wasm backend.

ubaidsk · 2023-02-15T22:11:04Z

We were hoping to use Array approach to store a complex number. In the Array approach, we had to reset the memory at the end of the function. To maintain where a function started (from which memory location), we are needing to store the memory offset in a (new/extra) local variable. Also, we currently have support only for memory allocation at compile-time. With these constraints, supporting the array approach seems tricky.

For the moment, to have something which just works I currently used two local variables to store a complex number.

ubaidsk · 2023-02-15T22:14:48Z

Some concerns:

the code for emit_complex_add_32(), emit_complex_add_64(), emit_complex_sub_32(), emit_complex_sub_64(), emit_complex_mul_32() and emit_complex_mul_64() altogether seems lengthy. Is it maintainable enough?
the function indices have been hard-coded when calling add_c32(), add_c64(), sub_32(), sub_64(), mul_32(), mul_64().

ubaidsk · 2023-02-15T22:18:42Z

src/libasr/codegen/asr_to_wasm.cpp

+            } else if (t->type == ASR::ttypeType::Complex) {
+                emit_call_fd_write(1, "(", 1, 0);
+                this->visit_expr(*x.m_values[i]);
+                wasm::emit_drop(m_code_section, m_al); // drop imag part
+                if (a_kind == 4) {
+                    wasm::emit_f64_promote_f32(m_code_section, m_al);
+                }
+                wasm::emit_call(m_code_section, m_al, 3  /* print_f64 */);
+                emit_call_fd_write(1, ",", 1, 0);
+                this->visit_expr(*x.m_values[i]);
+                if (a_kind == 4) {
+                    wasm::emit_f64_promote_f32(m_code_section, m_al);
+                }
+                wasm::emit_call(m_code_section, m_al, 3  /* print_f64 */);
+                emit_call_fd_write(1, ")", 1, 0);
+                wasm::emit_drop(m_code_section, m_al); // drop real part


Concern:
Line 2814 & Line 2826: When printing a complex number we print the real part and then the imaginary part. It currently happens that, when we fetch a complex number on stack top, the imaginary part of the complex is at the stack top followed by the real part. Thus, we are needing to drop the top stack so that we can print the appropriate real/imag part of the complex number.

This concern is now solved/fixed in WASM: handle_print(): Use globals and fix revisiting expr.

ubaidsk · 2023-02-16T23:35:30Z

From #1527 (comment),

Concern: the function indices have been hard-coded when calling add_c32(), add_c64(), sub_32(), sub_64(), mul_32(), mul_64().

This is now solved/fixed in WASM: Refactor: Define and use m_self_func_name_idx_map.

ubaidsk · 2023-02-16T23:41:15Z

src/libasr/codegen/asr_to_wasm.cpp

+        emit_complex_add_32();
+        emit_complex_add_64();
+        emit_complex_sub_32();
+        emit_complex_sub_64();
+        emit_complex_mul_32();
+        emit_complex_mul_64();
+        emit_complex_abs_32();
+        emit_complex_abs_64();


Ideally, these should be emitted into wasm code only when the particular operations are being used in the source code.

Concern/Challenge: If we do not define theses functions initally and add them at the very end (that is after defining all the other functions), then we do not have any function index to refer to these functions when they are called during a call (while defining the other functions).

I think I would keep a running index of all functions and just appending these at the end as needed; then once we are done, we convert the index to the function index at the start of the WASM binary file.

I attempted to support it in WASM: Support emitting functions based on requirement, and I'd love to get your feedback on it. Specifically, I'm wondering if this is what you had in mind, and if there are any changes you would like me to make. I'm open to any suggestions you have and would love to discuss this further with you.

ubaidsk · 2023-02-17T20:09:39Z

This is ready. Please review and share feedback.

czgdp1807 · 2023-02-18T05:01:42Z

the code for emit_complex_add_32(), emit_complex_add_64(), emit_complex_sub_32(), emit_complex_sub_64(), emit_complex_mul_32() and emit_complex_mul_64() altogether seems lengthy. Is it maintainable enough?

Can we somehow convert,

void emit_complex_add_32(int fn_idx = -1) {
        using namespace wasm;
        define_emit_func({f32, f32, f32, f32}, {f32, f32}, {}, "add_c32", [&](){
            wasm::emit_get_local(m_code_section, m_al, 0);
            wasm::emit_get_local(m_code_section, m_al, 2);
            wasm::emit_f32_add(m_code_section, m_al);

            wasm::emit_get_local(m_code_section, m_al, 1);
            wasm::emit_get_local(m_code_section, m_al, 3);
            wasm::emit_f32_add(m_code_section, m_al);
        }, fn_idx);
    }

to

(assuming type of f32, f64 is wasm::type and callback_type is say the type of wasm::emit_f32_add, wasm::emit_64_add and so on)

void emit_complex_op_util(wasm::type& ftype, std::string op_name, callback_type callback, int fn_idx = -1) {
        using namespace wasm;
        define_emit_func({ftype, ftype, ftype, ftype}, {ftype, ftype}, {}, op_name, [&](){
            wasm::emit_get_local(m_code_section, m_al, 0);
            wasm::emit_get_local(m_code_section, m_al, 2);
            callback(m_code_section, m_al);

            wasm::emit_get_local(m_code_section, m_al, 1);
            wasm::emit_get_local(m_code_section, m_al, 3);
            callback(m_code_section, m_al);
        }, fn_idx);
    }

and call it whereever needed.

ubaidsk · 2023-02-19T13:53:16Z

The callback seems to work for emit_complex_add_32 and emit_complex_add_64.

@czgdp1807 how do we use the similar callback approach in emit_complex_mul_32 or emit_complex_abs_32?

void emit_complex_mul_32(int fn_idx = -1) {
        using namespace wasm;
        define_emit_func({f32, f32, f32, f32}, {f32, f32}, {}, "mul_c32", [&](){
            wasm::emit_get_local(m_code_section, m_al, 0);
            wasm::emit_get_local(m_code_section, m_al, 2);
            wasm::emit_f32_mul(m_code_section, m_al);

            wasm::emit_get_local(m_code_section, m_al, 1);
            wasm::emit_get_local(m_code_section, m_al, 3);
            wasm::emit_f32_mul(m_code_section, m_al);

            wasm::emit_f32_sub(m_code_section, m_al);

            wasm::emit_get_local(m_code_section, m_al, 0);
            wasm::emit_get_local(m_code_section, m_al, 3);
            wasm::emit_f32_mul(m_code_section, m_al);

            wasm::emit_get_local(m_code_section, m_al, 1);
            wasm::emit_get_local(m_code_section, m_al, 2);
            wasm::emit_f32_mul(m_code_section, m_al);

            wasm::emit_f32_add(m_code_section, m_al);
        }, fn_idx);
    }

czgdp1807 · 2023-02-19T14:36:02Z

how do we use the similar callback approach in emit_complex_mul_32/64 or emit_complex_abs_32/64?

I guess we also need to support division of complex numbers. So some similar refactoring can be done for emit_complex_mul_32/64, emit_complex_div_32/64. emi_complex_abs_32/64 doesn't seem to have any common logic with add, mul, div, sub, so I guess it can be written independently without calling any utility function accepting callbacks.

ubaidsk · 2023-02-19T16:12:42Z

@czgdp1807 Refactoring emit_complex_mul_32 and emit_complex_mul_64 and combining them into one common function is not very clear to me. Please, could you share an example implementation where we refactor these two functions and combine them into one, similar to the transformation of emit_complex_add_32 as you shared in #1527 (comment)?

As a later change, I wonder if we can/should keep the functions emit_complex_mul_32/64, emit_complex_div_32/64. emi_complex_abs_32/64 in a separate file (maybe with some name like wasm_rt_lib.cpp). For the moment, shall we keep these as per the current implementation?

czgdp1807 · 2023-02-21T17:25:28Z

If you need it urgently then no need to refactor anything because that can be done later. If you have time to merge this, then may be figure out the patterns and create utility functions. The boilerplate code is high but that's okay. Just add TODOs before merging. I am approving it in its current state.

czgdp1807

Resolve conflicts then it should be good to go. Add TODOs for refactoring whevever you think refactoring can be done to reduce the boilerplate code. Thanks. cc: @certik

ubaidsk · 2023-02-21T17:37:02Z

If you have time to merge this, then may be figure out the patterns and create utility functions. The boilerplate code is high but that's okay.

Yes, these functions would later be implemented as ASR->ASR pass. Thus, I am unsure if we should refactor them now.

certik · 2023-02-21T17:40:20Z

src/libasr/codegen/asr_to_wasm.cpp

+        m_self_funcs_map["mul_c32"] = &ASRToWASMVisitor::emit_complex_mul_32;
+        m_self_funcs_map["mul_c64"] = &ASRToWASMVisitor::emit_complex_mul_64;
+        m_self_funcs_map["abs_c32"] = &ASRToWASMVisitor::emit_complex_abs_32;
+        m_self_funcs_map["abs_c64"] = &ASRToWASMVisitor::emit_complex_abs_64;


Let's use enums here for performance.

You can also then just use std::vector<bool> for all the enumerators, so it will be a very quick (constant) check.

This can be done in a subsequent PR.

certik · 2023-02-21T17:43:50Z

src/libasr/codegen/asr_to_wasm.cpp

+                if (a_kind == 4) {
+                    if (m_self_func_name_idx_map.find("add_c32") == m_self_func_name_idx_map.end()) {
+                        m_self_func_name_idx_map["add_c32"] = no_of_types++;
+                    }


This just becomes a quick check, like if (m_self_complex_fn_present[wasm_add_c32]).

certik

I think this is good to merge as is, after resolving conflicts / polishing history as needed.

In subsequent PRs we can refine.

WASM: Remove unused functions for ComplexIm

Also improve how global variables are declared

ubaidsk commented Feb 15, 2023

View reviewed changes

ubaidsk force-pushed the wasm_complex_nums3 branch from 1239af6 to 4dd3bff Compare February 16, 2023 23:31

ubaidsk commented Feb 16, 2023

View reviewed changes

ubaidsk force-pushed the wasm_complex_nums3 branch from 226c278 to 24b943a Compare February 17, 2023 19:58

ubaidsk marked this pull request as ready for review February 17, 2023 20:09

ubaidsk requested a review from certik February 17, 2023 20:11

czgdp1807 approved these changes Feb 21, 2023

View reviewed changes

certik reviewed Feb 21, 2023

View reviewed changes

certik approved these changes Feb 21, 2023

View reviewed changes

ubaidsk added 10 commits February 22, 2023 00:22

WASM: Implement complex numbers support

6e60000

WASM: Remove unused functions for ComplexIm

TEST: Split complex test case into two files

d059453

WASM: Minor fixes/improvements

1c51372

WASM: handle_print(): Use globals and fix revisiting expr

57d6715

WASM: Implement define_emit_func()

d9b1553

WASM: Refactor: Use define_emit_func()

cbf42cf

WASM: Refactor: Define and use m_global_var_name_idx_map

e2c6d99

Also improve how global variables are declared

WASM: Refactor: Define and use m_self_func_name_idx_map

07740ef

TEST: WASM: Enable supporting test for complex nums

90ddd9d

WAT: Fix/Improve support for globals

f792cd6

ubaidsk added 3 commits February 22, 2023 00:22

TEST: Update test_complex_01 to work with WAT

d22dc94

WASM: Support emitting functions based on requirement

0f92df6

TEST: WAT: Update reference tests

573d806

ubaidsk force-pushed the wasm_complex_nums3 branch from 9e04fd3 to 573d806 Compare February 21, 2023 18:55

ubaidsk enabled auto-merge February 21, 2023 18:56

ubaidsk merged commit 975eb1f into lcompilers:main Feb 21, 2023

ubaidsk deleted the wasm_complex_nums3 branch February 21, 2023 19:38

This was referenced Feb 21, 2023

WASM: Use enum to improve performance #1542

Merged

WASM: Sync backend from LPython lfortran/lfortran#1341

Merged

WASM: Initial support for complex numbers #1527

WASM: Initial support for complex numbers #1527

Uh oh!

Conversation

ubaidsk commented Feb 15, 2023 • edited by certik Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ubaidsk commented Feb 15, 2023

Uh oh!

ubaidsk commented Feb 15, 2023

Uh oh!

ubaidsk Feb 15, 2023

Choose a reason for hiding this comment

Uh oh!

ubaidsk Feb 16, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ubaidsk commented Feb 16, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ubaidsk Feb 16, 2023

Choose a reason for hiding this comment

Uh oh!

certik Feb 17, 2023

Choose a reason for hiding this comment

Uh oh!

ubaidsk Feb 17, 2023

Choose a reason for hiding this comment

Uh oh!

ubaidsk commented Feb 17, 2023

Uh oh!

czgdp1807 commented Feb 18, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ubaidsk commented Feb 19, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

czgdp1807 commented Feb 19, 2023

Uh oh!

ubaidsk commented Feb 19, 2023

Uh oh!

czgdp1807 commented Feb 21, 2023

Uh oh!

czgdp1807 left a comment

Choose a reason for hiding this comment

Uh oh!

ubaidsk commented Feb 21, 2023

Uh oh!

certik Feb 21, 2023

Choose a reason for hiding this comment

Uh oh!

certik Feb 21, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

certik Feb 21, 2023

Choose a reason for hiding this comment

Uh oh!

certik Feb 21, 2023

Choose a reason for hiding this comment

Uh oh!

certik left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

ubaidsk commented Feb 15, 2023 •

edited by certik

Loading

ubaidsk Feb 16, 2023 •

edited

Loading

ubaidsk commented Feb 16, 2023 •

edited

Loading

czgdp1807 commented Feb 18, 2023 •

edited

Loading

ubaidsk commented Feb 19, 2023 •

edited

Loading

certik Feb 21, 2023 •

edited

Loading