Don't compute FnAbi for LLVM intrinsics in backends#150768
Don't compute FnAbi for LLVM intrinsics in backends#150768rust-bors[bot] merged 3 commits intorust-lang:mainfrom
Conversation
|
These commits modify compiler targets. Some changes occurred in compiler/rustc_codegen_gcc |
|
r? @wesleywiser rustbot has assigned @wesleywiser. Use |
This comment has been minimized.
This comment has been minimized.
fb63e0c to
af005a9
Compare
This comment has been minimized.
This comment has been minimized.
e48fbd3 to
b05795a
Compare
This comment has been minimized.
This comment has been minimized.
b05795a to
83e77ec
Compare
This comment has been minimized.
This comment has been minimized.
83e77ec to
f1ab003
Compare
|
This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed. Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers. |
|
I've removed the removal of computing an |
|
@wesleywiser are you able to review this or should I reroll for review? |
| self, | ||
| sym, | ||
| fn_abi.llvm_cconv(self), | ||
| llvm::CCallConv, |
There was a problem hiding this comment.
Is this effectively just a lie? Or how does LLVM model the ABI for intrinsics? Is there a hidden assumption here that intrinsics only ever take ~integers/pointers that don't have any special handling in terms of ABI lowering of the arguments?
There was a problem hiding this comment.
This matches what was effectively done previously. I don't know if LLVM actually cares about the calling convention for intrinsics. It recognizes intrinsics based on a builtin list of symbol names. (if you declare an llvm.* function that doesn't match a known intrinsic, it will treat it like a regular function and emit an import of said function in the emitted object file)
| for fn_attr in fn_ty.fn_attributes { | ||
| func.add_attribute(fn_attr); | ||
| } | ||
| self.on_stack_function_params.borrow_mut().insert(func, FxHashSet::default()); |
There was a problem hiding this comment.
I guess this is the same ABI question as below - we're assuming there's no on-stack parameter passing since it's an intrinsic?
There was a problem hiding this comment.
extern "unadjusted" previously forced PassMode::Direct for all arguments, which means that on-stack parameters would never occur.
|
@bors r=wesleywiser |
…=wesleywiser Don't compute FnAbi for LLVM intrinsics in backends ~~This removes support for `extern "unadjusted"` for anything other than LLVM intrinsics. It only makes sense in the context of calling LLVM intrinsics anyway as it exposes the way the LLVM backend internally represents types. Perhaps it should be renamed to `extern "llvm-intrinsic"`?~~ Follow up to rust-lang#148533
…=wesleywiser Don't compute FnAbi for LLVM intrinsics in backends ~~This removes support for `extern "unadjusted"` for anything other than LLVM intrinsics. It only makes sense in the context of calling LLVM intrinsics anyway as it exposes the way the LLVM backend internally represents types. Perhaps it should be renamed to `extern "llvm-intrinsic"`?~~ Follow up to rust-lang#148533
…=wesleywiser Don't compute FnAbi for LLVM intrinsics in backends ~~This removes support for `extern "unadjusted"` for anything other than LLVM intrinsics. It only makes sense in the context of calling LLVM intrinsics anyway as it exposes the way the LLVM backend internally represents types. Perhaps it should be renamed to `extern "llvm-intrinsic"`?~~ Follow up to rust-lang#148533
Rollup of 17 pull requests Successful merges: - #142415 (Add note when inherent impl for a alias type defined outside of the crate) - #142680 (Fix passing/returning structs with the 64-bit SPARC ABI) - #150768 (Don't compute FnAbi for LLVM intrinsics in backends) - #151152 (Add FCW for derive helper attributes that will conflict with built-in attributes) - #151814 (layout: handle rigid aliases without params) - #151863 (Borrowck: simplify diagnostics for placeholders) - #152159 (Add note for `?Sized` params in int-ptr casts diag) - #152434 (Clarify names of `QueryVTable` functions for "executing" a query) - #152478 (Remove tm_factory field from CodegenContext) - #152498 (Partially revert "resolve: Update `NameBindingData::vis` in place") - #152316 (fix: add continue) - #152394 (Correctly check if a macro call is actually a macro call in rustdoc highlighter) - #152425 (Port #![test_runner] to the attribute parser) - #152481 (Use cg_ssa's produce_final_output_artifacts in cg_clif) - #152485 (fix issue#152482) - #152495 (Clean up some subdiagnostics) - #152502 (Implement `BinaryHeap::from_raw_vec`)
Rollup merge of #150768 - bjorn3:llvm_intrinsic_no_fn_abi, r=wesleywiser Don't compute FnAbi for LLVM intrinsics in backends ~~This removes support for `extern "unadjusted"` for anything other than LLVM intrinsics. It only makes sense in the context of calling LLVM intrinsics anyway as it exposes the way the LLVM backend internally represents types. Perhaps it should be renamed to `extern "llvm-intrinsic"`?~~ Follow up to #148533
This removes support forextern "unadjusted"for anything other than LLVM intrinsics. It only makes sense in the context of calling LLVM intrinsics anyway as it exposes the way the LLVM backend internally represents types. Perhaps it should be renamed toextern "llvm-intrinsic"?Follow up to #148533