LLVM intrinsic problem

Mojo
1

Hi, when compiling my mojo projects I’m getting an error:
Screenshot from 2025-03-26 22-32-59

And the piece of code causing it:

    @always_inline
    fn pext(self, b: BitBoard) -> UInt16:
        alias intrin = "llvm.x86.bmi.pext.64"
        return UInt16(llvm_intrinsic[intrin, UInt64](self.bb, b.bb))

Do anyone knows what is wrong?
My version of Mojo: mojo 25.3.0.dev2025032405

2

There’s somewhere that you’re running that at compile time, which LLVM doesn’t know how to do because that’s an x86 specific instruction. You can use is_compile_time to add a fallback path.

3

If I mark that I want to compile for a specific CPU that has this instruction available shouldn’t that fix a problem?

4

You could use @parameter if and queue the feature flags using sys.info:

Though the compile-time interpreter has limited capabilities:

5

I think the comptime interpreter should be able to fold roughly ~~any intrinsic that LLVM does. This doesn’t include target-specific things like llvm.x86.bmi.pext.64 (I agree is_comp_time is a good way to address that) but I’m seeing comments that it doesn’t support floor or bit intrinsics etc. Is that still true?

6

I think determining what can run at compile time is difficult for those of us outside of Modular don’t even have a good way to get the list of intrinsics without reading llvm source code. I’d ideally like to hook TableGen up to something that can spit out a few Mojo files so that we can better expose intrinsics without guesswork, but I think that might have to be part of the compiler build process. I think that most people also reach for the target specific options more readily, because they’re looking for “llvm pext intrinsic”, not the portable version, so they don’t see that the portable versions do work. We might want to guide people towards the portable options in order to avoid having lots of x86 specific code, since we should be able to polyfill a lot of things to have slower but at least functional code.

7

Simply answer, yes, that’s still true.

All related issues (That I know off):

8

It turns out that there were two separate problems that have both been fixed: we weren’t able to fold operations that returned integer simd results (like ctlz on SIMD) , and we weren’t able to fold index dialect operations (affecting Int and UInt). These have both been fixed now, it would be wonderful if you could check to see if all of those issues are fixed and if not, plz let me know.

Thank you @sora!

2 Likes