Skip to content

More altivec intrinsics #1443

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Merged
merged 4 commits into from
Jul 3, 2023
Merged

More altivec intrinsics #1443

merged 4 commits into from
Jul 3, 2023

Conversation

lu-zero
Copy link
Contributor

@lu-zero lu-zero commented Jun 25, 2023

vec_xl contains an ugly workaround since copy_nonoverlapping is not correctly inlined.

@rustbot
Copy link
Collaborator

rustbot commented Jun 25, 2023

r? @Amanieu

(rustbot has picked a reviewer for you, use r? to override)

@lu-zero lu-zero force-pushed the more-altivec-intrinsics branch from e430d84 to 8a92242 Compare June 25, 2023 15:07
@Amanieu
Copy link
Member

Amanieu commented Jun 29, 2023

The inlining issue happens because the PowerPC LLVM backend doesn't implement TargetTransformInfo::areInlineCompatible, so the default implementation is used which only allows inlining if the target features for the caller and callee match exactly. The target-specific specialized implementation typically allows inlining if the callee has a subset of the target feature of the caller.

Note that inline(always) skips this check, so this could be one way to make copy_nonoverlapping work in this case (you'd have to modify the standard library though).

@lu-zero
Copy link
Contributor Author

lu-zero commented Jun 30, 2023

We could have inline(always) for std::intrinsics and document the pitfall in case other architectures have the same problem.
It is probably a good idea to discuss with LLVM upstream about adding a complete areInlineCompatible for this arch as well...

@lu-zero lu-zero mentioned this pull request Jun 30, 2023
Merged
@nikic
Copy link
Contributor

nikic commented Jun 30, 2023

@Amanieu I believe https://reviews.llvm.org/D150396 will not allow inlining with incompatible target features even if alwaysinline is specified.

bors added a commit to rust-lang-ci/rust that referenced this pull request Jul 1, 2023
@bors
Auto merge of rust-lang#113194 - lu-zero:intrinsics-inline, r=thomcc
6b06fdf 
Mark wrapped intrinsics as inline(always)

This should mitigate having the inliner decide not to inline when the architecture is lacking an implementation of
TargetTransformInfo::areInlineCompatible aware of the target features (e.g. PowerPC as today).

See rust-lang/stdarch#1443 (comment)
@Amanieu
Copy link
Member

Amanieu commented Jul 3, 2023

Considering the upcoming LLVM changes, I think it's fine to merge with the current workaround. Ideally we'll want a proper implementation of areInlineCompatible in the future.

@Amanieu Amanieu merged commit a4cde4a into rust-lang:master Jul 3, 2023
thomcc pushed a commit to tcdi/postgrestd that referenced this pull request Aug 24, 2023
@bors
Auto merge of #113194 - lu-zero:intrinsics-inline, r=thomcc
27ad775 
Mark wrapped intrinsics as inline(always)

This should mitigate having the inliner decide not to inline when the architecture is lacking an implementation of
TargetTransformInfo::areInlineCompatible aware of the target features (e.g. PowerPC as today).

See rust-lang/stdarch#1443 (comment)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees

@Amanieu Amanieu

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
4 participants
@lu-zero @rustbot @Amanieu @nikic