#[inline(always)] + #[fixed_stack_segment] produces invalid IR

[brson]

#[inline(always)]
#[fixed_stack_segment]
pub unsafe fn JS_THIS_OBJECT(cx: *JSContext, vp: *JSVal) -> *JSObject {
    let r = JSVAL_TO_OBJECT(
        if JSVAL_IS_PRIMITIVE(*ptr::offset(vp, 1)) {
            JS_ComputeThis(cx, vp)
        } else {
            *ptr::offset(vp, 1)
        });
    r
}

Attributes 'noinline and alwaysinline' are incompatible!
%"enum.std::libc::types::common::c95::c_void[#1]"* ({ i64, %tydesc*, i8*, i8*, i8 }*, %"enum.std::libc::types::common::c95::c_void[#1]"*, %"struct.jsapi::JSVal"*)* @"_ZN14JS_TH\
IS_OBJECT13_8151e264a3f07_0$x2e1E"
Broken module found, compilation aborted!
Stack dump:
0.  Running pass 'Module Verifier' on function '@"_ZN14JS_THIS_OBJECT13_8151e264a3f07_0$x2e1E"'

[alexcrichton]

Is the correct handling of this to have a compiler error or to not have fixed_stack_segment imply inline(never)?

[nikomatsakis]

1. fixed_stack_segment should not imply inline(never). Changing this may expose other bugs in @pcwalton's llvm changes, though.
2. In an ideal world, we would modify the LLVM inliner so that it takes stack annotations into account when inlining. In this case, that would mean: do not inline fixed_stack_segment fns into other fns that are not annotated with fixed_stack_segment

[nikomatsakis]

see also #8822

[alexcrichton]

I thought I remembered reading code inside of LLVM which propagated the fixed_stack_segment attribute upwards once a function was inlined, but it may not have been what I thought it was.

[alexcrichton]

Closing in favor of #10155