Commit Graph

60 Commits

Author SHA1 Message Date
bors
397db054cb Auto merge of #75529 - bugadani:bounds-check, r=nagisa
Eliminate some other bound checks when index comes from an enum

#36962 introduced an assumption for the upper limit of the enum's value. This PR adds an assumption to the lower value as well.

I've modified the original codegen test to show that derived (in that case, adding 1) values also don't generate bounds checks.

However, this test is actually carefully crafted to not hit a bug: if the enum's variants are modified to 1 and 2 instead of 2 and 3, the test fails by adding a bounds check. I suppose this is an LLVM issue and #75525, while not exactly in this context should be tracking it.

I'm not at all confident if this patch can be accepted, or even if it _should_ be accepted in this state. But I'm curious about what others think :)

~Improves~ Should improve #13926 but does not close it because it's not exactly predictable, where bounds checks may pop up against the assumptions.
2020-09-01 13:36:52 +00:00
bors
6f1bbf5ee0 Auto merge of #76071 - khyperia:configurable_to_immediate, r=eddyb
Make to_immediate/from_immediate configurable by backends

`librustc_codegen_ssa` has the concept of an immediate vs. memory type, and `librustc_codegen_llvm` uses this distinction to implement `bool`s being `i8` in memory, and `i1` in immediate contexts. However, some of that implementation leaked into `codegen_ssa` when converting to/from immediate values. So, move those methods into builder traits, so that behavior can be configured by backends.

This is useful if a backend is able to keep bools as bools, or, needs to do more trickery than just bools to bytes.

(Note that there's already a large amount of things abstracted with "immediate types" - this is just bringing this particular thing in line to be abstracted as well)

---

Pinging @eddyb since that's who I was talking about this change with when they suggested I submit a PR.
2020-09-01 07:44:34 +00:00
Tyler Mandry
6d834a4046
Rollup merge of #76002 - richkadel:llvm-coverage-map-gen-6b.3, r=tmandry
Fix `-Z instrument-coverage` on MSVC

Found that `-C link-dead-code` (which was enabled automatically
under `-Z instrument-coverage`) was causing the linking error that
resulted in segmentation faults in coverage instrumented binaries. Link
dead code is now disabled under MSVC, allowing `-Z instrument-coverage`
to be enabled under MSVC for the first time.

More details are included in Issue #76038 .

Note this PR makes it possible to support `Z instrument-coverage` but
does not enable instrument coverage for MSVC in existing tests. It will be
enabled in another PR to follow this one (both PRs coming from original
PR #75828).

r? @tmandry
FYI: @wesleywiser
2020-08-31 19:18:14 -07:00
Rich Kadel
ddb054aee8 Fix -Z instrument-coverage on MSVC
Found that -C link-dead-code (which was enabled automatically
under -Z instrument-coverage) was causing the linking error that
resulted in segmentation faults in coverage instrumented binaries. Link
dead code is now disabled under MSVC, allowing `-Z instrument-coverage`
to be enabled under MSVC for the first time.

More details are included in Issue #76038.

(This PR was broken out from PR #75828)
2020-08-31 18:41:13 -07:00
Mateusz Mikuła
23f0ccfe5d Stabilise link-self-contained option 2020-08-31 15:13:31 +02:00
Dániel Buga
c88b167f15 Additional assumption to elide bounds check 2020-08-31 08:19:15 +02:00
Erik Desjardins
24e0913e37 handle vector layout 2020-08-30 14:58:03 -04:00
Erik Desjardins
68217c9e0f ignore zst offsets instead 2020-08-30 14:58:03 -04:00
David Wood
6ff471b1cf
ty: remove obsolete printer
This commit removes the obsolete printer and replaces all uses of it
with `FmtPrinter`. Of the replaced uses, all but one use was in `debug!`
logging, two cases were notable:

- `MonoItem::to_string` is used in `-Z print-mono-items` and therefore
  affects the output of all codegen-units tests.
- `DefPathBasedNames` was used in `librustc_codegen_llvm/type_of.rs`
  with `LLVMStructCreateNamed` and that'll now get different values, but
  this should result in no functional change.

Signed-off-by: David Wood <david@davidtw.co>
2020-08-30 18:59:07 +01:00
mark
9e5f7d5631 mv compiler to compiler/ 2020-08-30 18:45:07 +03:00