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
I've encountered an issue while compiling C code to WASM, and subsequently converting it to WAT. The issue pertains to the way string concatenation is handled in the WAT output. b.zip
Here's a snippet of my C source code snippet:
After compiling this C code to WASM and then converting it to WAT, I expected to find both strings 'Hello, ' and 'World!' in the data section of the WAT file. However, I could only find 'Hello, ' in the data section.
Instead of finding 'World!' as a contiguous string in the data section, I found it concatenated character by character in the function body, like so:
I'm puzzled by this behavior. Storing the strings in the data section seems to be a more efficient approach than concatenating them character by character in the function body. Is there a specific reason for this implementation? Could this be an optimization issue with the compiler?
The text was updated successfully, but these errors were encountered:
It's probably a target-independent optimization in upstream LLVM doing this. Are you compiling with -O2? If so, it may be worth trying with -Oz or -Os instead.
Hi, thanks for your suggestion! @sunfishcode
I try O0,O1,O2,O3,Os,Oz one by one, but only O0 has string 'Hello, ', and no one has string 'World!'
here is my cmd:
I've encountered an issue while compiling C code to WASM, and subsequently converting it to WAT. The issue pertains to the way string concatenation is handled in the WAT output.
b.zip
Here's a snippet of my C source code snippet:
After compiling this C code to WASM and then converting it to WAT, I expected to find both strings 'Hello, ' and 'World!' in the data section of the WAT file. However, I could only find 'Hello, ' in the data section.
Instead of finding 'World!' as a contiguous string in the data section, I found it concatenated character by character in the function body, like so:
I'm puzzled by this behavior. Storing the strings in the data section seems to be a more efficient approach than concatenating them character by character in the function body. Is there a specific reason for this implementation? Could this be an optimization issue with the compiler?
The text was updated successfully, but these errors were encountered: