about summary refs log tree commit diff
path: root/compiler/rustc_codegen_llvm/src/builder.rs
AgeCommit message (Collapse)AuthorLines
2022-03-01Auto merge of #94402 - erikdesjardins:revert-coldland, r=nagisabors-14/+3
Revert "Auto merge of #92419 - erikdesjardins:coldland, r=nagisa" Should fix (untested) #94390 Reopens #46515, #87055 r? `@ehuss`
2022-02-27Revert "Auto merge of #92419 - erikdesjardins:coldland, r=nagisa"Erik Desjardins-14/+3
This reverts commit 4f49627c6fe2a32d1fed6310466bb0e1c535c0c0, reversing changes made to 028c6f1454787c068ff5117e9000a1de4fd98374.
2022-02-27Apply noundef metadata to loads of types that do not permit raw initErik Desjardins-0/+14
This matches the noundef attributes we apply on arguments/return types.
2022-02-26Add LLVM attributes in batches instead of individuallyErik Desjardins-2/+8
This should improve performance.
2022-02-24Introduce Bx::switch_to_blockbjorn3-0/+4
2022-02-20Remove build_sibling_blockbjorn3-13/+11
2022-01-24Merge landing_pad and set_cleanup into cleanup_landing_padbjorn3-16/+18
2022-01-24Merge add_handler into catch_switchbjorn3-8/+8
Some codegen backends may require all handlers to be immediately known
2022-01-24Remove unused return values from resume and cleanup_retbjorn3-10/+9
Given that these instructions are diverging, not every codegen backend may be able to produce a return value for them.
2022-01-24Reorder unwinding related builder methods to differentiate between dwarf and ↵bjorn3-6/+6
msvc instructions
2022-01-17Update compiler/rustc_codegen_llvm/src/builder.rsCaleb Zulawski-3/+3
Co-authored-by: Jubilee <46493976+workingjubilee@users.noreply.github.com>
2022-01-04Add simd_as intrinsicCaleb Zulawski-18/+41
2021-12-30keep noinline for system llvm < 14Erik Desjardins-1/+8
2021-12-29Mark drop calls in landing pads cold instead of noinlineErik Desjardins-2/+2
Now that deferred inlining has been disabled in LLVM, this shouldn't cause catastrophic size blowup.
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.
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-24 13:54:14 +0000