bjorn3 [Sat, 30 Jan 2021 11:11:40 +0000 (12:11 +0100)]
Force stack slot size to be a multiple of 16
This ensures that all stack slots are aligned to 16 bytes. Without this
linking against crates compiled with cg_llvm may cause a crash due to
simd instructions requiring a 16 byte alignment.
bjorn3 [Fri, 25 Dec 2020 10:41:48 +0000 (11:41 +0100)]
Implement lazy compilation in JIT mode
Lazy compilation has the potential to significantly improve the startup
time of a program. While functions have to be codegened when called, it
is expected that a significant amount of all code is only required when
an error occurs or only when the program is used in certain ways.
The basic approach is to first codegen a shim for each function. This
shim calls the `__cg_clif_jit` function of cg_clif with a pointer to the
`Instance` corresponding to the function for which it is a shim.
`__cg_clif_jit` function then codegens this function and uses the hot
code swapping support of SimpleJIT to redirect future calls to the
function to the real version. Finally it calls the newly codegened
function.
bors [Wed, 9 Dec 2020 19:53:23 +0000 (19:53 +0000)]
Auto merge of #77611 - oli-obk:atomic_miri_leakage, r=nagisa
Directly use raw pointers in `AtomicPtr` store/load
I was unable to find any reason for this limitation in the latest source of LLVM or in the documentation [here](http://llvm.org/docs/Atomics.html#libcalls-atomic).
bors [Wed, 25 Nov 2020 07:25:19 +0000 (07:25 +0000)]
Auto merge of #79336 - camelid:rename-feature-oibit-to-auto, r=oli-obk
Rename `optin_builtin_traits` to `auto_traits`
They were originally called "opt-in, built-in traits" (OIBITs), but
people realized that the name was too confusing and a mouthful, and so
they were renamed to just "auto traits". The feature flag's name wasn't
updated, though, so that's what this PR does.
There are some other spots in the compiler that still refer to OIBITs,
but I don't think changing those now is worth it since they are internal
and not particularly relevant to this PR.
Also see <https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/opt-in.2C.20built-in.20traits.20(auto.20traits).20feature.20name>.
r? `@oli-obk` (feel free to re-assign if you're not the right reviewer for this)
Camelid [Mon, 23 Nov 2020 03:54:31 +0000 (19:54 -0800)]
Rename `optin_builtin_traits` to `auto_traits`
They were originally called "opt-in, built-in traits" (OIBITs), but
people realized that the name was too confusing and a mouthful, and so
they were renamed to just "auto traits". The feature flag's name wasn't
updated, though, so that's what this PR does.
There are some other spots in the compiler that still refer to OIBITs,
but I don't think changing those now is worth it since they are internal
and not particularly relevant to this PR.
Also see <https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/opt-in.2C.20built-in.20traits.20(auto.20traits).20feature.20name>.
bjorn3 [Thu, 12 Nov 2020 10:09:58 +0000 (11:09 +0100)]
Avoid muliplications by 1
```
Benchmark #1: ./raytracer_cg_clif_pre
Time (mean ± σ): 9.553 s ± 0.129 s [User: 9.543 s, System: 0.008 s]
Range (min … max): 9.438 s … 9.837 s 10 runs
Benchmark #2: ./raytracer_cg_clif_post
Time (mean ± σ): 9.463 s ± 0.055 s [User: 9.452 s, System: 0.008 s]
Range (min … max): 9.387 s … 9.518 s 10 runs
Summary
'./raytracer_cg_clif_post' ran
1.01 ± 0.01 times faster than './raytracer_cg_clif_pre'
```
Nicholas-Baron [Fri, 6 Nov 2020 21:24:55 +0000 (13:24 -0800)]
Changed unwrap_or to unwrap_or_else in some places.
The discussion seems to have resolved that this lint is a bit "noisy" in
that applying it in all places would result in a reduction in
readability.
A few of the trivial functions (like `Path::new`) are fine to leave
outside of closures.
The general rule seems to be that anything that is obviously an
allocation (`Box`, `Vec`, `vec![]`) should be in a closure, even if it
is a 0-sized allocation.
Dylan DPC [Mon, 9 Nov 2020 00:13:42 +0000 (01:13 +0100)]
Rollup merge of #78674 - tmiasko:inline-substs-for-mir-body, r=oli-obk
inliner: Use substs_for_mir_body
Changes from 68965 extended the kind of instances that are being
inlined. For some of those, the `instance_mir` returns a MIR body that
is already expressed in terms of the types found in substitution array,
and doesn't need further substitution.
Use `substs_for_mir_body` to take that into account.