about summary refs log tree commit diff
path: root/compiler/rustc_codegen_llvm/src/builder.rs
AgeCommit message (Collapse)AuthorLines
2021-12-16Remove `in_band_lifetimes` from `rustc_codegen_llvm`LegionMammal978-12/+12
See #91867 for more information.
2021-11-10Use more robust checks in rustc for wasmAlex Crichton-2/+2
2021-11-10Update more rustc/libtest things for wasm64Alex Crichton-2/+2
* Add wasm64 variants for inline assembly along the same lines as wasm32 * Update a few directives in libtest to check for `target_family` instead of `target_arch` * Update some rustc codegen and typechecks specialized for wasm32 to also work for wasm64.
2021-11-05Remove some minor checks for LLVM < 12Josh Stone-2/+2
2021-10-27Auto merge of #89652 - rcvalle:rust-cfi, r=nagisabors-0/+26
Add LLVM CFI support to the Rust compiler This PR adds LLVM Control Flow Integrity (CFI) support to the Rust compiler. It initially provides forward-edge control flow protection for Rust-compiled code only by aggregating function pointers in groups identified by their number of arguments. Forward-edge control flow protection for C or C++ and Rust -compiled code "mixed binaries" (i.e., for when C or C++ and Rust -compiled code share the same virtual address space) will be provided in later work as part of this project by defining and using compatible type identifiers (see Type metadata in the design document in the tracking issue #89653). LLVM CFI can be enabled with -Zsanitizer=cfi and requires LTO (i.e., -Clto). Thank you, `@eddyb` and `@pcc,` for all the help!
2021-10-25Add LLVM CFI support to the Rust compilerRamon de C Valle-0/+26
This commit adds LLVM Control Flow Integrity (CFI) support to the Rust compiler. It initially provides forward-edge control flow protection for Rust-compiled code only by aggregating function pointers in groups identified by their number of arguments. Forward-edge control flow protection for C or C++ and Rust -compiled code "mixed binaries" (i.e., for when C or C++ and Rust -compiled code share the same virtual address space) will be provided in later work as part of this project by defining and using compatible type identifiers (see Type metadata in the design document in the tracking issue #89653). LLVM CFI can be enabled with -Zsanitizer=cfi and requires LTO (i.e., -Clto).
2021-10-12Remap ssa RealPredicate to llvm RealPredicateTomasz Miąsko-0/+1
to avoid relying on the discriminant of the former for FFI purposes
2021-10-01Fix clippy lintsGuillaume Gomez-1/+1
2021-09-18Querify `fn_abi_of_{fn_ptr,instance}`.Eduard-Mihai Burtescu-1/+1
2021-09-18ty::layout: replicate `layout_of` setup for `fn_abi_of_{fn_ptr,instance}`.Eduard-Mihai Burtescu-2/+18
2021-09-09rename `is_valid_for` to `is_valid`Andreas Liljeqvist-1/+1
2021-09-09Make `abi::Abi` `Copy` and remove a *lot* of refsAndreas Liljeqvist-7/+7
fix fix Remove more refs and clones fix more fix
2021-09-09Remove `contains_zero`, respect the compilerAndreas Liljeqvist-1/+1
2021-09-09Add methods for checking for full ranges to `Scalar` and `WrappingRange`Andreas Liljeqvist-7/+6
Move *_max methods back to util change to inline instead of inline(always) Remove valid_range_exclusive from scalar Use WrappingRange instead implement always_valid_for in a safer way Fix accidental edit
2021-09-02ty::layout: split `LayoutOf` into required and (blanket) provided halves.Eduard-Mihai Burtescu-2/+2
2021-09-02ty::layout: implement `layout_of` automatically as a default method.Eduard-Mihai Burtescu-3/+4
2021-09-02rustc_target: move `LayoutOf` to `ty::layout`.Eduard-Mihai Burtescu-5/+4
2021-08-27rustc_target: add lifetime parameter to `LayoutOf`.Eduard-Mihai Burtescu-1/+1
2021-08-25Auto merge of #88242 - bonega:allocation_range, r=oli-obkbors-2/+1
Use custom wrap-around type instead of RangeInclusive Two reasons: 1. More memory is allocated than necessary for `valid_range` in `Scalar`. The range is not used as an iterator and `exhausted` is never used. 2. `contains`, `count` etc. methods in `RangeInclusive` are doing very unhelpful(and dangerous!) things when used as a wrap-around range. - In general this PR wants to limit potentially confusing methods, that have a low probability of working. Doing a local perf run, every metric shows improvement except for instructions. Max-rss seem to have a very consistent improvement. Sorry - newbie here, probably doing something wrong.
2021-08-23implement contains_zero methodAndreas Liljeqvist-2/+1
2021-08-22Use custom wrap-around type instead of RangeAndreas Liljeqvist-2/+2
2021-08-22Fix more “a”/“an” typosFrank Steffahn-1/+1
2021-08-05Prepare call/invoke for opaque pointersJosh Stone-22/+24
Rather than relying on `getPointerElementType()` from LLVM function pointers, we now pass the function type explicitly when building `call` or `invoke` instructions.
2021-08-04Prepare inbounds_gep for opaque pointersTomasz Miąsko-3/+13
Implement inbounds_gep using LLVMBuildInBoundsGEP2 which takes an explicit type argument instead of deriving it from a pointer type.
2021-08-04Prepare gep for opaque pointersTomasz Miąsko-2/+3
Implement gep using LLVMBuildGEP2 which takes an explicit type argument instead of deriving it from a pointer type.
2021-08-04Prepare struct_gep for opaque pointersTomasz Miąsko-3/+4
Imlement struct_gep using LLVMBuildStructGEP2 which takes an explicit type argument instead of deriving it from a pointer type.
2021-07-18Auto merge of #86950 - tmiasko:personality, r=nagisabors-1/+5
Use existing declaration of rust_eh_personality If crate declares `rust_eh_personality`, re-use existing declaration as otherwise attempts to set function attributes that follow the declaration will fail (unless it happens to have exactly the same type signature as the one predefined in the compiler). Fixes #70117. Fixes https://github.com/rust-lang/rust/pull/81469#issuecomment-809428126; probably.
2021-07-10Set personality with LLVMSetPersonalityFnTomasz Miąsko-1/+5
2021-07-09Pass type when creating loadNikita Popov-20/+9
This makes load generation compatible with opaque pointers. The generation of nontemporal copies still accesses the pointer element type, as fixing this requires more movement.
2021-07-09Pass type when creating atomic loadNikita Popov-0/+2
Instead of determining it from the pointer type, explicitly pass the type to load.
2021-06-23Use HTTPS links where possibleSmitty-1/+1
2021-06-02Miscellaneous inlining improvementsTomasz Miąsko-0/+3
2021-05-17rustc_codegen_ssa: append blocks to functions w/o creating a builder.Eduard-Mihai Burtescu-21/+25
2021-05-17rustc_codegen_ssa: only create backend `BasicBlock`s as-needed.Eduard-Mihai Burtescu-4/+0
2021-04-23Disable LLVM's new fptoint intrinsics on riscv64Alex Crichton-2/+10
Looks like this platform still isn't quite working yet due to https://bugs.llvm.org/show_bug.cgi?id=50083
2021-04-21rustc: Use LLVM's new saturating float-to-int intrinsicsAlex Crichton-65/+28
This commit updates rustc, with an applicable LLVM version, to use LLVM's new `llvm.fpto{u,s}i.sat.*.*` intrinsics to implement saturating floating-point-to-int conversions. This results in a little bit tighter codegen for x86/x86_64, but the main purpose of this is to prepare for upcoming changes to the WebAssembly backend in LLVM where wasm's saturating float-to-int instructions will now be implemented with these intrinsics. This change allows simplifying a good deal of surrounding code, namely removing a lot of wasm-specific behavior. WebAssembly no longer has any special-casing of saturating arithmetic instructions and the need for `fptoint_may_trap` is gone and all handling code for that is now removed. This means that the only wasm-specific logic is in the `fpto{s,u}i` instructions which only get used for "out of bounds is undefined behavior". This does mean that for the WebAssembly target specifically the Rust compiler will no longer be 100% compatible with pre-LLVM 12 versions, but it seems like that's unlikely to be relied on by too many folks. Note that this change does immediately regress the codegen of saturating float-to-int casts on WebAssembly due to the specialization of the LLVM intrinsic not being present in our LLVM fork just yet. I'll be following up with an LLVM update to pull in those patches, but affects a few other SIMD things in flight for WebAssembly so I wanted to separate this change. Eventually the entire `cast_float_to_int` function can be removed when LLVM 12 is the minimum version, but that will require sinking the complexity of it into other backends such as Cranelfit.
2021-04-17Don't set `fast`(-math) for certain simd opsSimonas Kazlauskas-9/+9
`fast-math` implies things like functions not being able to accept as an argument or return as a result, say, `inf` which made these functions confusingly named or behaving incorrectly, depending on how you interpret it. Since the time when these intrinsics have been implemented the intrinsics user's (stdsimd) approach has changed significantly and so now it is required that these intrinsics operate normally rather than in "whatever" way. Fixes #84268
2021-03-26Use iter::zip in compiler/Josh Stone-6/+3
2021-02-14Replace const_cstr with cstr crateXidorn Quan-4/+4
2021-01-18Use ty::{IntTy,UintTy,FloatTy} in rustcLeSeulArtichaut-2/+1
2020-10-30Fix even more clippy warningsJoshua Nelson-4/+1
2020-10-21rustc_codegen_llvm: expose DILocation to rustc_codegen_ssa.Eduard-Mihai Burtescu-0/+1
2020-10-17Make set_span take mut selfkhyperia-1/+1
2020-10-15Replace target.target with target and target.ptr_width with target.pointer_widthest31-6/+6
Preparation for a subsequent change that replaces rustc_target::config::Config with its wrapped Target. On its own, this commit breaks the build. I don't like making build-breaking commits, but in this instance I believe that it makes review easier, as the "real" changes of this PR can be seen much more easily. Result of running: find compiler/ -type f -exec sed -i -e 's/target\.target\([)\.,; ]\)/target\1/g' {} \; find compiler/ -type f -exec sed -i -e 's/target\.target$/target/g' {} \; find compiler/ -type f -exec sed -i -e 's/target.ptr_width/target.pointer_width/g' {} \; ./x.py fmt
2020-10-06Let backends access span informationkhyperia-1/+3
Sometimes, a backend may need to emit warnings, errors, or otherwise need to know the span of the current item in a basic block. So, add a set_span method to give the backend that information.
2020-09-26Rollup merge of #77211 - est31:remove_unused_allow, r=oli-obkRalf Jung-1/+0
Remove unused #[allow(...)] statements from compiler/
2020-09-26Remove unused #[allow(...)] statements from compiler/est31-1/+0
2020-09-24Remove TrustedLen requirement from BuilderMethods::switchest31-2/+1
The main use case of TrustedLen is allowing APIs to specialize on it, but no use of it uses that specialization. Instead, only the .len() function provided by ExactSizeIterator is used, which is already required to be accurate. Thus, the TrustedLen requirement on BuilderMethods::switch is redundant.
2020-09-04Change ty.kind to a methodLeSeulArtichaut-2/+2
2020-09-01Auto merge of #76071 - khyperia:configurable_to_immediate, r=eddybbors-3/+16
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.
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2025-11-12 19:04:31 +0000