Skip to content

Inlining + target_feature broken in powerpc64 #60637

Description

@gnzlbg

godbolt

#![feature(repr_simd, powerpc_target_feature)]
#![allow(non_camel_case_types)]

#[repr(simd)] pub struct u32x4(u32, u32, u32, u32);

impl u32x4 {
    #[inline]
    // #[inline(always)]
    fn splat(x: u32) -> Self {
        u32x4(x, x, x, x)
    }
}

#[target_feature(enable = "altivec")]
pub unsafe fn splat_u32x4(x: u32) -> u32x4 {
    u32x4::splat(x)
}

with #[inline] that code produces a function call within splat_u32x4 (b example::u32x4::splat) to u32x4::splat, which is not eliminated, even though this method is module private. With #[inline(always)], u32x4::splat is inlined into splat_u32x4, and no code for u32x4::splat is generated.

#[inline] should not be needed here, much less #[inline(always)], yet without #[inline(always)] this produces bad codegen.

Removing the #[target_feature] attribute from splat_u32x4 fixes the issue, no #[inline] necessary: godbolt. So there must be some interaction between inlining and target features going on here.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-LLVMArea: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues.A-SIMDArea: SIMD (Single Instruction Multiple Data)C-bugCategory: This is a bug.O-PowerPCTarget: PowerPC processorsT-compilerRelevant to the compiler team, which will review and decide on the PR/issue.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions