Skip to content

cfg_target_feature and target_feature don't interact properly #42515

Open
@parched

Description

@parched
Contributor

This should panic but it doesn`t

#[target_feature = "+avx"]
pub fn should_panic() {
#[cfg(target_feature = "avx")]
    panic!("have_avx");
}

I would like for this to work because I have a macro that generates 2 copys of a function, one with #[target_feature = "+feat"] and one without and I want to conditionally use some assembly when the feature is available.

CC #29717

Activity

BurntSushi

BurntSushi commented on Jun 8, 2017

@BurntSushi
Member

It does panic.

#![feature(cfg_target_feature, target_feature)]

#[target_feature = "+avx"]
fn should_panic() {
    #[cfg(target_feature = "avx")]
    panic!("have_avx");
}

fn main() {
    should_panic();
}
$ rustc -C target-feature=+avx rust42515.rs
$ ./rust42515 
thread 'main' panicked at 'have_avx', rust42515.rs:6
note: Run with `RUST_BACKTRACE=1` for a backtrace.

If you don't compile with the appropriate target-feature settings, then the cfg is not set and the program (correctly) does not panic. I think you can think of -C target-feature=+avx similarly as gcc's -mavx flag.

parched

parched commented on Jun 8, 2017

@parched
ContributorAuthor

But #[target_feature = "+avx"] should set it for that function without passing anything extra on the command line.

BurntSushi

BurntSushi commented on Jun 8, 2017

@BurntSushi
Member

What do gcc and clang do? Can you explain more about your use case and why you expect this to happen?

parched

parched commented on Jun 8, 2017

@parched
ContributorAuthor

Well gcc and c only have the preprocessor macros so that would behave like cfg_target_feature currently does. However, I assumed rust attributes are more context aware.

parched

parched commented on Jun 8, 2017

@parched
ContributorAuthor

My use case is for this procedural macro attribute I've written https://github.com/parched/runtime-target-feature-rs which generates 2 copies of the function, one with #[target_feature = "+feat"] and one without. I would like to have some conditional code based on which copies is being compiled.

BurntSushi

BurntSushi commented on Jun 8, 2017

@BurntSushi
Member

@parched gcc and Clang have the equivalent of #[target_feature] as well, e.g., __target__("avx") can be applied to functions. Both gcc and Clang support that. So I would be very interested to see how their preprocessor macros interact with __target__("avx") (if at all).

I assumed rust attributes are more context aware

To give you some context, the #[target_feature] attribute is highly experimental. Its only purpose is to expose an LLVM feature directly so that we can experiment with it to help move along the SIMD stabilization effort. What its iteraction with #[cfg(target_feature)] is isn't clear at this time, so detailed use cases would be very helpful.

I would like to have some conditional code based on which copies is being compiled.

But #[target_feature] isn't a conditional compilation flag. You need to do some kind of runtime dispatch using cpuid to figure out which function to execute. I still don't understand the use case for using cfg(target_feature) inside a #[target_feature] function.

parched

parched commented on Jun 8, 2017

@parched
ContributorAuthor

More explicitly the macro I've written, runtime_target_feature turns

#[runtime_target_feature("+avx")]
pub fn sum(input: &[u32]) -> u32 {
    #[cfg(target_feature = "avx")]
    { /* write some assembly using avx */ }

    #[cfg(not(target_feature = "avx"))]
    { /* fallback code */ input.iter().sum()}
}
pub fn sum(input: &[u32]) -> u32 {
    pub extern crate runtime_target_feature_rt as rt;

    static PTR: rt::atomic::Atomic<fn (&[u32]) -> u32> = rt::atomic::Atomic::new(setup);

    fn setup(input: &[u32]) -> u32 {
        let chosen_function = if rt::have_avx( ) { // have_avx reads cpuid
            enable_avx
        } else {
            default
        };
        PTR.store(chosen_function, rt::atomic::Ordering::Relaxed);
        chosen_function(input)
    }

    fn default(input: &[u32]) -> u32 {
        #[cfg(target_feature = "avx")]
        { /* write some assembly using avx */ }

        #[cfg(not(target_feature = "avx"))]
        { /* fallback code */ input.iter().sum()} // I would like this compiled here
    }

    #[target_feature = "+avx"]
    fn enable_avx(input: &[u32] ) -> u32 {
        #[cfg(target_feature = "avx")]
        { /* write some assembly using avx */ } // but this compiled here

        #[cfg(not(target_feature = "avx"))]
        { /* fallback code */ input.iter().sum()}
    }

    PTR.load(rt::atomic::Ordering::Relaxed)(input)
}
parched

parched commented on Jun 8, 2017

@parched
ContributorAuthor

@BurntSushi I mean they only have macros for detecting the target features so the couldn't possibly change inside a function with __target__("avx") which is annoying. It would be great if rust cfg could be smarter than that though :)

BurntSushi

BurntSushi commented on Jun 8, 2017

@BurntSushi
Member

@parched Sorry, but I still don't understand your use case. What problem are you trying to solve at a high level? For example, having a cfg(not(target_feature = "avx")) inside a #[target_feature = "+avx"] function just doesn't make any sense to me at all. If you wind up calling a #[target_feature = "+avx"] function when avx isn't actually enabled, then you're in trouble no matter what.

BurntSushi

BurntSushi commented on Jun 8, 2017

@BurntSushi
Member

And I still don't understand what's fundamentally different between Rust's system and gcc's/Clang's. I think you need to back way up and help me try to understand what specific problems you're facing.

TimNN

TimNN commented on Jun 8, 2017

@TimNN
Contributor

@BurntSushi: I think the use case here is a matter of convenience: Write a function in which some parts are marked #[cfg(target_feature = "avx")] or #[cfg(not(target_feature = "avx"))], then use a macro to create two versions (copies) of that function, one with #[target_feature = "+avx"] and one without, along with supporting code to choose the correct one at runtime.

The difference to gcc/Clang is, as I understand it, that since the preprocessor runs before any c parsing happens it cannot know if it is inside a function marked __target__("avx"), whereas the rust compiler should be / is / could be well aware that it's currently looking at a #[cfg(target_feature = "avx")] inside a function marked #[target_feature = "+avx"].

BurntSushi

BurntSushi commented on Jun 8, 2017

@BurntSushi
Member

@TimNN Thanks for explaining that. It makes a little more sense, although I don't understand why the macro can't just strip out the cfg'd code that's never going to execute.

Popping up a level, I'm not particularly familiar with this aspect of the compiler (can arbitrary attributes impact the resolution of cfgs?) and I don't know if we have any precedent for it.

parched

parched commented on Jun 8, 2017

@parched
ContributorAuthor

Yes just what TimNN says. @BurntSushi I was actually just thinking that on my bike ride home and that would definitely work. It would mean the macro would need to know all the target features and their hierarchy. I.e., if the feature enabled was sse3 the macro would have to know to strip out any cfg not sse2.

17 remaining items

Loading
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-SIMDArea: SIMD (Single Instruction Multiple Data)A-target-featureArea: Enabling/disabling target features like AVX, Neon, etc.C-bugCategory: This is a bug.T-langRelevant to the language team

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @alexcrichton@RalfJung@BurntSushi@nagisa@gnzlbg

        Issue actions

          `cfg_target_feature` and `target_feature` don't interact properly · Issue #42515 · rust-lang/rust