The frontend shouldn't be deciding whether or not to use mutable
noalias attributes, as this is a pure LLVM concern. Only provide
the necessary information and do the actual decision in
codegen_llvm.
This seems right, given that conceptually bools are unsigned, but the
implications of this change may have more action at distance that I'm
not sure how to exhaustively consider.
For instance there are a number of cases where code attaches range
metadata if `scalar.is_bool()` holds. Supposedly it would no longer be
attached to the `repr(i8)` enums? Though I'm not sure why booleans are
being special-cased here in the first place...
Fixes#80556
Split a func into cold/hot parts, reducing binary size
I noticed that the Size::bits function is called in many places,
and is inlined into them. On x86_64-pc-windows-msvc, this function
is inlined 527 times, and compiled separately (non-inlined) 3 times.
Each of those inlined calls contains code that panics. This commit
moves the `panic!` call into a separate function and marks that
function with `#[cold]`.
This reduces binary size by 24 KB. Not much, but it's something.
Changes like this often reduce pressure on instruction-caches,
since it reduces the amount of code that is inlined into hot code
paths. Or more precisely, it removes cold code from hot cache lines.
I noticed that the Size::bits function is called in many places,
and is inlined into them. On x86_64-pc-windows-msvc, this function
is inlined 527 times, and compiled separately (non-inlined) 3 times.
Each of those inlined calls contains code that panics. This commit
moves the `panic!` call into a separate function and marks that
function with `#[cold]`.
This reduces binary size by 24 KB. By itself, that's not a substantial
reduction. However, changes like this often reduce pressure on
instruction-caches, since it reduces the amount of code that is inlined
into hot code paths. Or more precisely, it removes cold code from hot
cache lines. It also removes all conditionals from Size::bits(),
which is called in many places.
Rename target_pointer_width to pointer_width because it is already
member of the Target struct.
The compiler supports only three valid values for target_pointer_width:
16, 32, 64. Thus it can safely be turned into an int.
This means less allocations and clones as well as easier handling of the type.
