runtime: RuntimeInformation.ProcessArchitecture is not a JIT constant

Description

RuntimeInformation.ProcessArchitecture currently isn’t a JIT time constant so it doesn’t participate in dead branch elimination and it also isn’t inlined. Since the API has a simillar usage as OperatingSystem APIs which are JIT constants, the expected behaviour would be for it to be as optimized as them. The simple solution would be to store the value in a static readonly field and return that instead, which would be optimized in T1.

Thinking about it though, I think that since the process architecture will be always the same as the one dotnet running it was built for, wouldn’t such implementation as the one below be valid?

        public static Architecture ProcessArchitecture
        {
            get
            {
#if TARGET_ARM64
                return Architecture.Arm64;
#elif TARGET_ARM
                return Architecture.Arm;
#elif TARGET_AMD64
                return Architecture.X64;
#elif TARGET_X86
                return Architecture.X86;
#elif TARGET_WASM
                return Architecture.Wasm;
#elif TARGET_S390X
                return Architecture.S390x;
#else
#error Unknown Architecture
#endif
            }
        }

Configuration

SharpLab Core CLR 5.0.721.25508 on amd64

Regression?

Probably not

Data

SharpLab

About this issue

  • Original URL
  • State: closed
  • Created 3 years ago
  • Reactions: 3
  • Comments: 15 (14 by maintainers)

Commits related to this issue

Most upvoted comments

it turned out we can’t use architecture-based preprocessors or partials for this assembly

You can fix that by moving the type to CoreLib. CoreLib is built as architecture-specific.

Other option could be to have a named intrinsic for it in JIT:

That would require moving the type to CoreLib as well. We do not like having JIT intrinsics outside CoreLib.

OSArchitecture coming through the interop layer at least for x86 (and probably also for arm32). JIT named intrinsic can help in this case.

OSArchitecture is very rarely used and never on performance critical paths. I do not think it would be worth it to add JIT intrinsic for it.