You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In add_top_mem, the call remains f (⊤:%mem.M, argc_1111242, return_1111250).
In add_top_mem, the call is changed to f (_1113823, argc_1113827, return_1113835).
The only difference between the two examples are the externals g and h (h seems to be the important one).
It seems like mems in application argument position are sometimes taken in consideration as current memory.
However, we should only consider vars and application results.
The text was updated successfully, but these errors were encountered:
The behavior was probably caused due to the sharing of the two ⊤:%mem.M instances.
The fix is in the ho_codegen branch (the only place where it is currently needed) and will be merged with it.
The
add_mem
phase behaves differently, depending on surrounding externals.Even if these externals are never called and to not interfere with the functions.
Example: https://github.com/NeuralCoder3/thorin2/blob/ho_codegen/lit/mem/add_top_mem.thorin
Example2: https://github.com/NeuralCoder3/thorin2/blob/ho_codegen/lit/mem/add_top_mem2.thorin
In
add_top_mem
, the call remainsf (⊤:%mem.M, argc_1111242, return_1111250)
.In
add_top_mem
, the call is changed tof (_1113823, argc_1113827, return_1113835)
.The only difference between the two examples are the externals
g
andh
(h
seems to be the important one).It seems like mems in application argument position are sometimes taken in consideration as current memory.
However, we should only consider vars and application results.
The text was updated successfully, but these errors were encountered: