901: Set target triple and datalayout when creating the LLVM module. r=nlewycky a=nlewycky
We were giving LLVM a triple and datalayout only when producing native code from the LLVM IR. With this change, we tell LLVM as early as possible so that the entire optimization stack knows that it's safe to use target-specific constructs (including target intrinsics `@llvm.x86.sse2.ucomieq.sd`) as well as cost models (for autovectorization) and knowing the bitwidth of the registers so that we can know it's profitable to eliminate redundant extend/truncate casts.
Co-authored-by: Nick Lewycky <nick@wasmer.io>
904: Use getelementptr instruction instead of int_to_ptr and ptr_to_int. r=nlewycky a=nlewycky
The main part of this change is that we no longer turn pointers into integers to do arithmetic on them, then turn them back into pointers. Doing so is a signal to LLVM that it should not attempt to analyze the provenance of the pointers, disabling some optimizations. Using getelementptr allows us to perform arithmetic on pointers while keeping them in pointer types, which LLVM can then analyze.
Most of the textual change is a refactoring to reorder the operations. Previously the bounds checking and determining of the base and bounds were combined because you could put both into the same match, since both actions are performed differently depending on whether the memory is static or dynamic. In this case, we simply check the type twice and do two different things, with comments labelling the steps.
Co-authored-by: Nick Lewycky <nick@wasmer.io>
ptr_to_int and int_to_ptr are not treated the same as type-safe pointer operations. LLVM intentionally performs fewer optimizations to code using the former as compared with the latter. We don't need that in our code, standard pointer optimizations are safe for us.
Instead of ensuring outputs are arithmetic NaNs on every function, we tag them as pending such a check, so that a sequence of computation can have a single canonicalization step at the end.
There's an extra wriggle for SIMD. The Wasm type system only indicates them as V128, so it's possible that we might do computations as F32x4Add, I8x16Add, F64x2Add in a row with no other computations in between. Thus, most SIMD functions apply pending canonicalizations to their inputs, even integer SIMD operations.
863: Rewrite Min/Max to handle all cases correctly. Fixes 545 spectest failures. r=nlewycky a=nlewycky
# Description
The llvm backend was not quite following the Wasm spec for {F32,F64,F32x4xF64x2}{Min,Max}. We used the `@llvm.minnum` and `@llvm.maxnum` intrinsics which don't handle the corner cases the same. When we tried to use `@llvm.minimum` and `@llvm.maximum` which do, we get an internal error from the x86 backend. I was hoping that crash would go away with the upgrade to LLVM 9, but it does not.
Reimplement these operations using plain LLVM instructions.
# Review
- [x] Add a short description of the the change to the CHANGELOG.md file
Co-authored-by: Nick Lewycky <nick@wasmer.io>
870: Fix unused value warning due to inkwell API change. NFC. r=nlewycky a=nlewycky
# Description
Fix unused value warning due to inkwell API change. No functionality change.
Co-authored-by: Nick Lewycky <nick@wasmer.io>
Use them to implement three features in the LLVM backend, getting a valid ELF object file, the post-optimization LLVM IR and the pre-optimization LLVM IR.
Presently they are also global to the backend which is not ideal.
Not handled here is @llvm.minnum and @llvm.maxnum which should be replaced with
@llvm.minimum and @llvm.maximum, but using those currently leads to LLVM backend
fatal errors.
