xip: Lookup float constants from table to reduce relocations #894

wenyongh · 2021-12-15T04:54:53Z

Lookup float/double constants from exec_env->native_symbol table
but not construct them with LLVMBuildConst if XIP mode is enabled,
these constants are introduced by f32/f64.const opcodes and some
float/double conversion opcodes, and make wamrc generate some
relocations in text section of AOT XIP file. This patch eliminates such
relocations when "--enable-indirect-mode" is added to wamrc.

Merge bytecodealliance:main into wenyongh:refine_xip

lum1n0us · 2021-12-16T02:06:11Z

core/iwasm/aot/aot_loader.c


-#if defined(BH_PLATFORM_WINDOWS)
 static bool
 str2uint32(const char *buf, uint32 *p_res)


what is the difference between str2uint32 to the strtol from libc ?

@lum1n0us Seems the result of str2uint32 is a raw hex rather than an integer

Yes, it is raw int bits of f32 and f64.

xujuntwt95329 · 2021-12-16T02:09:19Z

core/iwasm/compilation/aot_llvm.c

+            const_ptr_type = INT64_PTR_TYPE;
+            break;
+        case VALUE_TYPE_F32:
+            snprintf(buf, sizeof(buf), "i32#%08X", value->i32);


Suggested change

snprintf(buf, sizeof(buf), "i32#%08X", value->i32);

snprintf(buf, sizeof(buf), "i32#%08X", value->f32);

Seems there should be f32?

Should be i32, store the raw int bits to make it simple and avoid data loss (possible data loss when using f32, e.g. NaN values).

xujuntwt95329 · 2021-12-16T02:12:57Z

core/iwasm/compilation/aot_llvm.c

+    }
+
+    memset(sym, 0, sizeof(AOTNativeSymbol));
+    snprintf(sym->symbol, sizeof(sym->symbol), "%s", symbol);


Should we add an assert to ensure the symbol is no longer than the buffer?

bh_assert(strlen(symbol) <= sizeof(sym->symbol));

lum1n0us · 2021-12-16T08:57:39Z

core/iwasm/aot/aot_loader.c

-                set_error_buf_v(error_buf, error_buf_size,
-                                "missing native symbol: %s", symbol);
-                goto fail;
+            if (!strncmp(symbol, "i32#", 4)) {


may let i32 be renamed n32. less confusion over i representing integer and f representing float.

has renamed to "f32#"

yamt · 2022-04-19T09:46:55Z

@wenyongh
do you think it makes sense to do similar for i32.const etc?
it can save some of relocations from wasi-libc printf implementation on x86-64.

wenyongh · 2022-04-20T00:52:36Z

@yamt it depends, not sure how much footprint it can reduce and how much performance it will impact? I remember that many x86 instructions directly encode i32 immediate as its operand, the performance should be better than that of looking up i32 immediate from the constant table.

yamt · 2022-04-20T01:05:57Z

@yamt it depends, not sure how much footprint it can reduce and how much performance it will impact? I remember that many x86 instructions directly encode i32 immediate as its operand, the performance should be better than that of looking up i32 immediate from the constant table.

i'm not sure how much impact it is.
do you have a better idea to eliminate these relocations?

wenyongh · 2022-04-20T01:24:45Z

Is it only required by XIP mode? For non-XIP, no need to eliminate these relocations, right? Seems no other good idea except do the similar for i32.const.
Add @no1wudi to discuss.

yamt · 2022-04-20T01:27:05Z

Is it only required by XIP mode? For non-XIP, no need to eliminate these relocations, right?

yes

Seems no other good idea except do the similar for i32.const. Add @no1wudi to discuss.

ok

no1wudi · 2022-04-20T01:38:34Z

@yamt Could you share more info (disassembly code, etc) about which instruction will lead to relocation in your application ?

yamt · 2022-04-20T02:37:36Z

@yamt Could you share more info (disassembly code, etc) about which instruction will lead to relocation in your application ?

just "hello world" using printf.
libc from wasi-sdk-14.0-macos.tar.gz.

for example, a constant 100000000 (00e1f505) is loaded from .rodata.cst4, it seems.

Contents of section .rodata.cst4:
 0000 01000000 00e1f505 0a000000           ............

    316d: 41 89 cb                      movl    %ecx, %r11d
    3170: 48 8b 7c 24 50                movq    80(%rsp), %rdi
    3175: 85 d2                         testl   %edx, %edx
    3177: 0f 88 01 01 00 00             js      0x327e <aot_func#29+0x18ae>
    317d: 31 ed                         xorl    %ebp, %ebp
    317f: 45 39 de                      cmpl    %r11d, %r14d
    3182: 48 bf 00 00 00 00 00 00 00 00 movabsq $0, %rdi
                0000000000003184:  R_X86_64_64  .rodata.cst4+0x4
    318c: 73 2e                         jae     0x31bc <aot_func#29+0x17ec>
    318e: 48 8b 84 24 90 00 00 00       movq    144(%rsp), %rax
    3196: 44 29 f0                      subl    %r14d, %eax
    3199: c1 f8 02                      sarl    $2, %eax
    319c: 8d 2c c0                      leal    (%rax,%rax,8), %ebp
    319f: 44 89 f0                      movl    %r14d, %eax
    31a2: 41 8b 44 05 00                movl    (%r13,%rax), %eax
    31a7: 83 f8 0a                      cmpl    $10, %eax
    31aa: 72 10                         jb      0x31bc <aot_func#29+0x17ec>
    31ac: b9 0a 00 00 00                movl    $10, %ecx
    31b1: ff c5                         incl    %ebp
    31b3: 01 c9                         addl    %ecx, %ecx
    31b5: 8d 0c 89                      leal    (%rcx,%rcx,4), %ecx
    31b8: 39 c8                         cmpl    %ecx, %eax

maybe this one in printf_core, but i'm not sure.

 001d87: 03 40                      |                             loop
 001d89: 20 11                      |                               local.get 17
 001d8b: 41 80 c2 d7 2f             |                               i32.const 100000000
 001d90: 6c                         |                               i32.mul
 001d91: 21 11                      |                               local.set 17
 001d93: 20 16                      |                               local.get 22
 001d95: 41 08                      |                               i32.const 8
 001d97: 6a                         |                               i32.add
 001d98: 22 16                      |                               local.tee 22
 001d9a: 0d 00                      |                               br_if 0
 001d9c: 0b                         |                             end

…ealliance#894) Lookup float/double constants from exec_env->native_symbol table but not construct them with LLVMBuildConst if XIP mode is enabled, these constants are introduced by f32/f64.const opcodes and some float/double conversion opcodes, and make wamrc generate some relocations in text section of AOT XIP file. This patch eliminates such relocations when "--enable-indirect-mode" is added to wamrc.

wenyongh added 3 commits December 13, 2021 01:46

Load const from table for xip

241edb7

only handle f32/f64 const and float conversions

f3a6b3b

Merge pull request #420 from bytecodealliance/main

f988d4f

Merge bytecodealliance:main into wenyongh:refine_xip

lum1n0us reviewed Dec 16, 2021

View reviewed changes

xujuntwt95329 reviewed Dec 16, 2021

View reviewed changes

lum1n0us reviewed Dec 16, 2021

View reviewed changes

wenyongh merged commit 5be427b into bytecodealliance:main Dec 16, 2021

wenyongh added 2 commits December 17, 2021 01:20

Refine code, add comments

bdc4721

Fix typo

cd5a06f

wenyongh deleted the refine_xip branch December 19, 2021 00:33

	snprintf(buf, sizeof(buf), "i32#%08X", value->i32);
	snprintf(buf, sizeof(buf), "i32#%08X", value->f32);

xip: Lookup float constants from table to reduce relocations #894

xip: Lookup float constants from table to reduce relocations #894

Uh oh!

Conversation

wenyongh commented Dec 15, 2021

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

yamt commented Apr 19, 2022

Uh oh!

wenyongh commented Apr 20, 2022

Uh oh!

yamt commented Apr 20, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

wenyongh commented Apr 20, 2022

Uh oh!

yamt commented Apr 20, 2022

Uh oh!

no1wudi commented Apr 20, 2022

Uh oh!

yamt commented Apr 20, 2022

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

yamt commented Apr 20, 2022 •

edited

Loading