hungryzzz

Hi, I just investigated futher why this case would produce bugs. The original bug case is as blow: ``` #include struct a { short b; unsigned int c; int d...

> My understanding of the situation is the following: errors like this are due to the fact that the release version has assertion disabled, so there might code-paths that are...

@fitzgen I use the CLI to run the case, the command I use is `wasmtime good.wasm` without extra flags.

@fitzgen Thank you for your advice, I recollect the execution time with the above commands and the results are as follows. I guess the JITed code would be cached after...

I use `Perf` tool to profile the execution time and surprisingly find that the hotspot is not in `func1` where the small difference happens, but in the `func2`. I continue...

> Is it changing the alignment of `func2`? Yes, the machine codes of `func2` before and after changes are the same excpet the start address of the `func2`. ```shell #...

> Would you be willing to send a PR to update the alignment on x86-64? Someone else can do it if not, but hopefully it's an easy-ish change! Hi, I...

> The problem isn't actually with branch prediction, but with the way the instruction fetch works on most modern superscalar machines. The `func2` would be called many times, in my...

> I think it's just [this constant](https://github.com/bytecodealliance/wasmtime/blob/c477424f45871563be02eba14815ba3446158441/cranelift/codegen/src/isa/x64/inst/mod.rs#L2705-L2707) that needs to be changed; probably with a comment update noting that we're aligning for better formance and a link to this issue?...

Thank you for your reply! But I still confused that what makes the different JIT modes to generate different binary sequence which cause different multiplication results? In addition, could you...