https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=1.50.0 2020-12-11T02:25:40+00:00 2020-12-11T02:25:40+00:00 Tomasz Miąsko tomasz.miasko@gmail.com 2020-12-11T00:00:00+00:00 urn:sha1:686237c49aed588bf266e8dece3130b779605109 This allows const propagation to evaluate comparisons involving field-less enums using derived implementations of `PartialEq` (after inlining `eq`). 2020-11-16T21:34:57+00:00 Bastian Kauschke bastian_kauschke@hotmail.de 2020-10-24T00:21:18+00:00 urn:sha1:2bf93bd852f0636eb4d052ee155bdb6cec592c53 2020-11-07T00:00:00+00:00 Tomasz Miąsko tomasz.miasko@gmail.com 2020-11-07T00:00:00+00:00 urn:sha1:f78f36cdb79db07ae2b650426fd42c94a2f29ae9 This wasn't necessary until MIR inliner started to consider drop glue as a candidate for inlining; introducing for the first time a generic use of size-of operation. No test at this point since this only happens with a custom inlining threshold. 2020-09-04T15:47:51+00:00 LeSeulArtichaut leseulartichaut@gmail.com 2020-08-02T22:49:11+00:00 urn:sha1:3e14b684dd31794e8dbe6acd7a5f132997ee0c47 2020-09-01T13:36:52+00:00 bors bors@rust-lang.org 2020-09-01T13:36:52+00:00 urn:sha1:397db054cb1f3d98e3d2809d25c60f1979cd5a97 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-01T07:44:34+00:00 bors bors@rust-lang.org 2020-09-01T07:44:34+00:00 urn:sha1:6f1bbf5ee014cdad5d95f13266b177d89cc40d89 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-08-31T06:19:15+00:00 Dániel Buga bugadani@gmail.com 2020-08-30T19:26:03+00:00 urn:sha1:c88b167f1518370833c9216706d09735d1e2d697 2020-08-30T15:45:07+00:00 mark markm@cs.wisc.edu 2020-08-28T03:58:48+00:00 urn:sha1:9e5f7d5631b8f4009ac1c693e585d4b7108d4275