394 Commits

Author SHA1 Message Date
Antoni Boucher
4d3d0d492f Fix intrinsic/generic-arithmetic-pass.rs test 2024-07-02 12:28:44 -04:00
Antoni Boucher
cd014cda8c Replace the type of global variables instead of replacing them 2024-07-02 12:28:25 -04:00
Antoni Boucher
bbc765b49b Fix clippy warnings 2024-07-02 12:27:31 -04:00
Antoni Boucher
21b1b11981 WIP: Implement dummy ThinLTO
FIXME: This seems very slow.
==> Not sure anymore: compare with the master branch.
2024-07-02 12:27:25 -04:00
Antoni Boucher
9ca7658817 Fix tests 2024-07-02 12:27:18 -04:00
Antoni Boucher
e8e6663167 Fix provenance intrinsics 2024-07-02 12:25:29 -04:00
Antoni Boucher
0ffcbb0f6e Remove the hack in zext
TODO: make sure this doesn't break something else.
2024-07-02 12:24:47 -04:00
Guillaume Gomez
dd4a546de0 Add explanations for ptr func call argument cast 2024-07-02 12:24:11 -04:00
Guillaume Gomez
527c049584 Fix warnings 2024-07-02 12:24:07 -04:00
Guillaume Gomez
ca654047fb Add missing cast for function_ptr arguments 2024-07-02 12:24:03 -04:00
Guillaume Gomez
30ee7ba862 Add shl and shr missing casts 2024-07-02 12:23:55 -04:00
Guillaume Gomez
068fe5d10a If the type of a global is not the same, we remove the global and replace it with a new one 2024-07-02 12:23:33 -04:00
Guillaume Gomez
621e948721 Fix clippy lint 2024-07-02 12:21:25 -04:00
Guillaume Gomez
7615e04f82 Fix usage of get_size for gcc 12 2024-07-02 12:20:47 -04:00
Guillaume Gomez
9b1211db58 Fix casts 2024-07-02 12:20:42 -04:00
Guillaume Gomez
580e5ba456 Format code 2024-07-02 12:20:34 -04:00
Guillaume Gomez
f848dbbda5 Fix non-master build 2024-07-02 12:20:30 -04:00
bjorn3
994041a40c Remove type_i1 and type_struct from cg_ssa
They are not representable by Cranelift
2024-06-21 19:30:26 +00:00
bjorn3
8a1e58169a Remove check_overflow method from MiscMethods
It can be retrieved from the Session too.
2024-06-21 19:30:26 +00:00
bjorn3
9d25e851ce Remove const_bitcast from ConstMethods 2024-06-21 19:26:07 +00:00
Oli Scherer
cb1bde07c1 Remove redundant argument from subdiagnostic method 2024-06-18 15:42:11 +00:00
Oli Scherer
527b3575ba Use a dedicated type instead of a reference for the diagnostic context
This paves the way for tracking more state (e.g. error tainting) in the diagnostic context handle
2024-06-18 15:42:11 +00:00
Ralf Jung
d565d3d23d ScalarInt: size mismatches are a bug, do not delay the panic 2024-06-10 13:43:16 +02:00
Michael Goulet
b2d39816ba Uplift TypeRelation and Relate 2024-06-01 12:50:58 -04:00
Guillaume Gomez
a1d293337c Rollup merge of #125345 - durin42:thin-link-bitcode, r=bjorn3
rustc_codegen_llvm: add support for writing summary bitcode

Typical uses of ThinLTO don't have any use for this as a standalone file, but distributed ThinLTO uses this to make the linker phase more efficient. With clang you'd do something like `clang -flto=thin -fthin-link-bitcode=foo.indexing.o -c foo.c` and then get both foo.o (full of bitcode) and foo.indexing.o (just the summary or index part of the bitcode). That's then usable by a two-stage linking process that's more friendly to distributed build systems like bazel, which is why I'm working on this area.

I talked some to `@teresajohnson` about naming in this area, as things seem to be a little confused between various blog posts and build systems. "bitcode index" and "bitcode summary" tend to be a little too ambiguous, and she tends to use "thin link bitcode" and "minimized bitcode" (which matches the descriptions in LLVM). Since the clang option is thin-link-bitcode, I went with that to try and not add a new spelling in the world.

Per `@dtolnay,` you can work around the lack of this by using `lld --thinlto-index-only` to do the indexing on regular .o files of bitcode, but that is a bit wasteful on actions when we already have all the information in rustc and could just write out the matching minimized bitcode. I didn't test that at all in our infrastructure, because by the time I learned that I already had this patch largely written.
2024-05-23 23:39:26 +02:00
Augie Fackler
4a79b06f83 rustc_codegen_gcc: fix changed method signature 2024-05-23 15:23:21 -04:00
Augie Fackler
29fc479a30 rustc_codegen_llvm: add support for writing summary bitcode
Typical uses of ThinLTO don't have any use for this as a standalone
file, but distributed ThinLTO uses this to make the linker phase more
efficient. With clang you'd do something like `clang -flto=thin
-fthin-link-bitcode=foo.indexing.o -c foo.c` and then get both foo.o
(full of bitcode) and foo.indexing.o (just the summary or index part of
the bitcode). That's then usable by a two-stage linking process that's
more friendly to distributed build systems like bazel, which is why I'm
working on this area.

I talked some to @teresajohnson about naming in this area, as things
seem to be a little confused between various blog posts and build
systems. "bitcode index" and "bitcode summary" tend to be a little too
ambiguous, and she tends to use "thin link bitcode" and "minimized
bitcode" (which matches the descriptions in LLVM). Since the clang
option is thin-link-bitcode, I went with that to try and not add a new
spelling in the world.

Per @dtolnay, you can work around the lack of this by using `lld
--thinlto-index-only` to do the indexing on regular .o files of
bitcode, but that is a bit wasteful on actions when we already have all
the information in rustc and could just write out the matching minimized
bitcode. I didn't test that at all in our infrastructure, because by the
time I learned that I already had this patch largely written.
2024-05-22 14:04:22 -04:00
Scott McMurray
cae9e7ec6a Stop using to_hir_binop in codegen 2024-05-22 01:34:26 -07:00
Santiago Pastorino
21f58e4bc4 Rename Unsafe to Safety 2024-05-17 18:33:37 -03:00
bors
06f1ba4f65 Auto merge of #124972 - matthiaskrgr:rollup-3fablim, r=matthiaskrgr
Rollup of 5 pull requests

Successful merges:

 - #124615 (coverage: Further simplify extraction of mapping info from MIR)
 - #124778 (Fix parse error message for meta items)
 - #124797 (Refactor float `Primitive`s to a separate `Float` type)
 - #124888 (Migrate `run-make/rustdoc-output-path` to rmake)
 - #124957 (Make `Ty::builtin_deref` just return a `Ty`)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-05-10 16:04:26 +00:00
Matthias Krüger
ce11a86648 Rollup merge of #124797 - beetrees:primitive-float, r=davidtwco
Refactor float `Primitive`s to a separate `Float` type

Now there are 4 of them, it makes sense to refactor `F16`, `F32`, `F64` and `F128` out of `Primitive` and into a separate `Float` type (like integers already are). This allows patterns like `F16 | F32 | F64 | F128` to be simplified into `Float(_)`, and is consistent with `ty::FloatTy`.

As a side effect, this PR also makes the `Ty::primitive_size` method work with `f16` and `f128`.

Tracking issue: #116909

`@rustbot` label +F-f16_and_f128
2024-05-10 16:10:46 +02:00
Ralf Jung
7ad734687c codegen: memmove/memset cannot be non-temporal 2024-05-09 18:59:00 +02:00
Nicholas Nethercote
6b7db50d89 Simplify use crate::rustc_foo::bar occurrences.
They can just be written as `use rustc_foo::bar`, which is far more
standard. (I didn't even know that a `crate::` prefix was valid.)
2024-05-08 16:57:31 +10:00
beetrees
f26221a936 Refactor float Primitives to a separate Float type 2024-05-06 14:56:10 +01:00
bors
efa15ebfef Auto merge of #123441 - saethlin:fixed-len-file-names, r=oli-obk
Stabilize the size of incr comp object file names

The current implementation does not produce stable-length paths, and we create the paths in a way that makes our allocation behavior is nondeterministic. I think `@eddyb` fixed a number of other cases like this in the past, and this PR fixes another one. Whether that actually matters I have no idea, but we still have bimodal behavior in rustc-perf and the non-uniformity in `find` and `ls` was bothering me.

I've also removed the truncation of the mangled CGU names. Before this PR incr comp paths look like this:
```
target/debug/incremental/scratch-38izrrq90cex7/s-gux6gz0ow8-1ph76gg-ewe1xj434l26w9up5bedsojpd/261xgo1oqnd90ry5.o
```
And after, they look like this:
```
target/debug/incremental/scratch-035omutqbfkbw/s-gux6borni0-16r3v1j-6n64tmwqzchtgqzwwim5amuga/55v2re42sztc8je9bva6g8ft3.o
```

On the one hand, I'm sure this will break some people's builds because they're on Windows and only a few bytes from the path length limit. But if we're that seriously worried about the length of our file names, I have some other ideas on how to make them smaller. And last time I deleted some hash truncations from the compiler, there was a huge drop in the number if incremental compilation ICEs that were reported: https://github.com/rust-lang/rust/pull/110367https://github.com/rust-lang/rust/pull/110367

---

Upon further reading, this PR actually fixes a bug. This comment says the CGU names are supposed to be a fixed-length hash, and before this PR they aren't: ca7d34efa9/compiler/rustc_monomorphize/src/partitioning.rs (L445-L448)
2024-05-03 17:41:48 +00:00
Matthias Krüger
7ed351a508 Rollup merge of #124624 - WaffleLapkin:old_unit, r=fmease
Use `tcx.types.unit` instead of `Ty::new_unit(tcx)`

I don't think there is any need for the function, given that we can just access the `.types`, similarly to all other primitives?
2024-05-02 19:42:50 +02:00
Waffle Lapkin
3ea32a746d Inline & delete Ty::new_unit, since it's just a field access 2024-05-02 17:49:23 +02:00
Mark Rousskov
2b875f0927 Step bootstrap cfgs 2024-05-01 22:19:11 -04:00
bors
752af44fc4 Auto merge of #122053 - erikdesjardins:alloca, r=nikic
Stop using LLVM struct types for alloca

The alloca type has no semantic meaning, only the size (and alignment, but we specify it explicitly) matter. Using `[N x i8]` is a more direct way to specify that we want `N` bytes, and avoids relying on LLVM's struct layout. It is likely that a future LLVM version will change to an untyped alloca representation.

Split out from #121577.

r? `@ghost`
2024-04-24 03:00:44 +00:00
Ben Kimock
2d082aedf7 Stabilize the size of incr comp object file names 2024-04-22 10:50:07 -04:00
bors
0f17e5ae23 Auto merge of #117919 - daxpedda:wasm-c-abi, r=wesleywiser
Introduce perma-unstable `wasm-c-abi` flag

Now that `wasm-bindgen` v0.2.88 supports the spec-compliant C ABI, the idea is to switch to that in a future version of Rust. In the meantime it would be good to let people test and play around with it.

This PR introduces a new perma-unstable `-Zwasm-c-abi` compiler flag, which switches to the new spec-compliant C ABI when targeting `wasm32-unknown-unknown`.

Alternatively, we could also stabilize this and then deprecate it when we switch. I will leave this to the Rust maintainers to decide.

This is a companion PR to #117918, but they could be merged independently.
MCP: https://github.com/rust-lang/compiler-team/issues/703
Tracking issue: https://github.com/rust-lang/rust/issues/122532
2024-04-19 03:35:10 +00:00
Erik Desjardins
50a147152d restore location in gcc alloca codegen 2024-04-12 08:36:22 -04:00
Erik Desjardins
4ea338942b use [N x i8] for alloca types 2024-04-11 21:42:35 -04:00
Scott McMurray
cccf379a5b Put PlaceValue into OperandValue::Ref, rather than 3 tuple fields 2024-04-11 00:10:10 -07:00
Scott McMurray
b9b05d5a23 Make PlaceRef hold a PlaceValue for the non-layout fields (like OperandRef does) 2024-04-11 00:10:10 -07:00
Michael Baikov
040afd36f3 Save/restore more items in cache with incremental compilation 2024-04-06 10:59:24 -04:00
bors
27ba1bad27 Auto merge of #118310 - scottmcm:three-way-compare, r=davidtwco
Add `Ord::cmp` for primitives as a `BinOp` in MIR

Update: most of this OP was written months ago.  See https://github.com/rust-lang/rust/pull/118310#issuecomment-2016940014 below for where we got to recently that made it ready for review.

---

There are dozens of reasonable ways to implement `Ord::cmp` for integers using comparison, bit-ops, and branches.  Those differences are irrelevant at the rust level, however, so we can make things better by adding `BinOp::Cmp` at the MIR level:

1. Exactly how to implement it is left up to the backends, so LLVM can use whatever pattern its optimizer best recognizes and cranelift can use whichever pattern codegens the fastest.
2. By not inlining those details for every use of `cmp`, we drastically reduce the amount of MIR generated for `derive`d `PartialOrd`, while also making it more amenable to MIR-level optimizations.

Having extremely careful `if` ordering to μoptimize resource usage on broadwell (#63767) is great, but it really feels to me like libcore is the wrong place to put that logic.  Similarly, using subtraction [tricks](https://graphics.stanford.edu/~seander/bithacks.html#CopyIntegerSign) (#105840) is arguably even nicer, but depends on the optimizer understanding it (https://github.com/llvm/llvm-project/issues/73417) to be practical.  Or maybe [bitor is better than add](https://discourse.llvm.org/t/representing-in-ir/67369/2?u=scottmcm)?  But maybe only on a future version that [has `or disjoint` support](https://discourse.llvm.org/t/rfc-add-or-disjoint-flag/75036?u=scottmcm)?  And just because one of those forms happens to be good for LLVM, there's no guarantee that it'd be the same form that GCC or Cranelift would rather see -- especially given their very different optimizers.  Not to mention that if LLVM gets a spaceship intrinsic -- [which it should](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Suboptimal.20inlining.20in.20std.20function.20.60binary_search.60/near/404250586) -- we'll need at least a rustc intrinsic to be able to call it.

As for simplifying it in Rust, we now regularly inline `{integer}::partial_cmp`, but it's quite a large amount of IR.  The best way to see that is with 8811efa88b (diff-d134c32d028fbe2bf835fef2df9aca9d13332dd82284ff21ee7ebf717bfa4765R113) -- I added a new pre-codegen MIR test for a simple 3-tuple struct, and this PR change it from 36 locals and 26 basic blocks down to 24 locals and 8 basic blocks.  Even better, as soon as the construct-`Some`-then-match-it-in-same-BB noise is cleaned up, this'll expose the `Cmp == 0` branches clearly in MIR, so that an InstCombine (#105808) can simplify that to just a `BinOp::Eq` and thus fix some of our generated code perf issues.  (Tracking that through today's `if a < b { Less } else if a == b { Equal } else { Greater }` would be *much* harder.)

---

r? `@ghost`
But first I should check that perf is ok with this
~~...and my true nemesis, tidy.~~
2024-04-02 19:21:44 +00:00
Matthias Krüger
1ee4ae9eb2 Rollup merge of #122937 - Zalathar:unbox, r=oli-obk
Unbox and unwrap the contents of `StatementKind::Coverage`

The payload of coverage statements was historically a structure with several fields, so it was boxed to avoid bloating `StatementKind`.

Now that the payload is a single relatively-small enum, we can replace `Box<Coverage>` with just `CoverageKind`.

This patch also adds a size assertion for `StatementKind`, to avoid accidentally bloating it in the future.

``@rustbot`` label +A-code-coverage
2024-03-24 17:08:16 +01:00
Scott McMurray
1a05106f94 Add+Use mir::BinOp::Cmp 2024-03-23 23:23:41 -07:00
Matthew Maurer
abbe1ba6f2 CFI: Use Instance at callsites
We already use `Instance` at declaration sites when available to glean
additional information about possible abstractions of the type in use.
This does the same when possible at callsites as well.

The primary purpose of this change is to allow CFI to alter how it
generates type information for indirect calls through `Virtual`
instances.
2024-03-23 18:30:39 +00:00