feat: optimize string literal tostack behavior

[HerrCai0907]

String literals are widely used static data, and our GC algorithm does not recycle them (see

assemblyscript/std/assembly/rt/itcms.ts

Line 244 in 7e2a62d

if (changetype<usize>(obj) < __heap_base) {

). Recording the addresses of all string literals and preventing the emission of tostack code can effectively improve performance

[HerrCai0907]

In bootstrap parse, the execution time reduced from 210ms to 200ms.

[CountBleck]

This optimization looks very promising (so cool that you found this!). I can definitely see the difficulty of making something equivalent to Set<i64> that works in the JS build.

My understanding of this PR is that you're trying to add the if (address < __heap_base) shortcut to the shadow stack generation code, and staticGcObjectOffsets is how you're trying to determine (for needToStack) whether some data is static data. Do you think it's possible to instead directly compare the address/offset to the value of __heap_base?

If this isn't easy or possible within the compiler, what would generating something like this (well, the isize equivalent) look like (assuming this idea is easy to do):

(if (i32.lt_u (local.get $address) (global.get $~lib/memory/__heap_base))
    (; insert tostack code here ;)
)

Would Binaryen optimize that out, even in debug builds? Just throwing some backup ideas out, because I'm not a huge fan of staticGcObjectOffsets (but if we can't do it any other way, I guess we have no choice).

[HerrCai0907]

My understanding of this PR is that you're trying to add the if (address < __heap_base) shortcut to the shadow stack generation code, and staticGcObjectOffsets is how you're trying to determine (for needToStack) whether some data is static data. Do you think it's possible to instead directly compare the address/offset to the value of __heap_base?

That is wrong. e.g. StaticArray also in data segments but we should add it to stack otherwise all of the A in this array will be free.

The precise description should be the so-called pointee free type located in the static data area. But string literal is the most common used type. So I also add string to the map. But we can extend it later.

[CountBleck]

Ah, understood.