Chris Fallin

> Hi, could I ask why the function alignment could affect the CPU branch prediction? Thanks! I addressed this a few comments up: > FWIW, the usual "fetch bandwidth sin"...

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?

> > 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...

For a few more pieces of anecdata: basic RISC-V (integer/FP only, no SIMD, not too many opts) took about three months in review and was ~21k lines of code. Back...

It looks like more or less a full copy of the aarch64 backend, with find-replace ("copy-n-rename" as @ecnelises noted above); I was curious if there were any e.g. instruction emission...

No one has indicated they're working on it, so if you or anyone who is familiar with Windows on Arm is willing to build it, we'd very much welcome it!

@lpereira how are the loop / basic-block weights computed in the .NET JIT? Are they based on profiling counters or some ahead-of-time estimate? It'd be helpful to see a summary...

@yuyang-ok unfortunately this seems to be failing a number of tests now -- bad merge?

Indeed; to add a little more, the overall approach I want to take is to integrate the egraph data structure more completely into the `DataFlowGraph`. Basically, the `PrimaryMap` of `ValueDef`s...

Yep, we could go further in that direction as well; that's an interesting direction to explore.