The main follow-up item to
https://github.com/llvm/llvm-project/pull/160790 was changing -O0
codegen to convert in-memory i8 bool values to i1 with the `nonzero`
rule (`icmp ne i8 %val, 0`) rather than the `truncate` rule (`trunc i8
%val to i1`).
Bool values can only be `true` or `false`. While they are notionally a
single bit, the smallest addressable unit is CHAR_BIT bits large, and
CHAR_BIT is typically 8. Programming errors (such as memcpying a random
byte to a `bool`) can cause the 8-bit storage for a `bool` value to have
a bit pattern that is different from `true` or `false`, which then leads
to undefined behavior.
Clang has historically taken advantage of this in optimized builds
(everything other than -O0) by attaching range metadata to `bool` loads
to assume that the value loaded can only be 0 or 1. This leads to
exploitable security issues, and the correct behavior is not always easy
to explain to C developers. To remedy this situation, Clang accepted a
[-fstrict-bool](https://discourse.llvm.org/t/defining-what-happens-when-a-bool-isn-t-0-or-1/86778)
switch to control whether it can assume that loaded bool values are
always necessarily 0 or 1. By default, it does (maintaining the status
quo), and users must specify `-fno-strict-bool` to opt out of that
behavior.
When opting out, users can optionally request that bool i8 values are
converted to i1 either by truncation or by comparing to 0. The default
is comparing to 0. However, since `-O0` alone _technically_ uses
-fstrict-bool, unoptimized builds convert i8 bool values to i1 with a
`trunc` operation, whereas `-O1 -fno-strict-bool` converts i8 bool
values to i1 with `icmp ne 0`. This is a surprising inconsistency.
This PR changes -O0 codegen to align with -fno-strict-bool. This is
achieved with a single-line change:
```
bool isConvertingBoolWithCmp0() const {
switch (getLoadBoolFromMem()) {
case BoolFromMem::Strict:
+ return !isOptimizedBuild();
case BoolFromMem::Truncate:
```
However, it impacts a _very large_ number of tests, so we agreed to move
it out of the -fstrict-bool PR to reduce the chances we would have to
back out the whole thing for this secondary item.
This PR does the change and modifies the tests accordingly. I expect
that it will go stale rather quickly. If this needs more discussion,
I'll only update it once we reach consensus.
d28a8b0b3f