Allow FPU flag override

[franksinankaya]

Provide two environment variables as CLR_FPU_FLAGOVERRIDE to specify the VFP option in use such as vfpv3-d16 and CLR_FPU_CAPABILITY bitmask to tell which precision registers are actually implemented.

value of CLR_FPU_CAPABILITY is bit 0 for half, bit 1 for single and bit 2 for double precision.

[franksinankaya]

@jkotas @janvorli @BruceForstall

[franksinankaya]

Use

export CLR_FPU_CAPABILITY=0x3
export CLR_FPU_FLAGOVERRIDE="vfpv3-d16"

to build with vfpv3-d16 as an example

[janvorli]

I don't like controlling the build scripts via environment variables. If we don't want to add an explicit option to our build scripts, I'd prefer using cmake properties instead. But it seems ok to add a build.sh option for this. @jkotas I am not sure what you really meant by your comment dotnet/coreclr#27890 (comment) that seems to make @franksinankaya opt for the env variable way.

[franksinankaya]

I think the concern is we have too many ARMXYZ variants. I could bring the vfp options up all the way to build.sh instead of environment variables.

[jkotas]

I agree that the environment variables are not the best way to do this.

We have a generic way to pass defines from the build command line to build. It is used to control number of features contributed by community that are not turned on in the default build. For example, dotnet/coreclr#13567

This should use the same scheme.

[franksinankaya]

These feature flags don't seem to work in compiler detection stage in "configurecompiler.cmake"

[franksinankaya]

should I reorder include(clrdefinitions.cmake) ? or create a clrcompilerdefinitions.cmake?

[janvorli]

I am not sure I understand the problem. It think that you should be able to pass an extra cmake variabled using the -cmakeargs option (e.g. -cmakeargs -DCLR_FPU_CAPABILITY=0x7 -cmakeargs -DCLR_FPU_FLAGOVERRIDE=vfpv3) and then use these cmake variables instead of the env vars in your current implementation.

[franksinankaya]

Cool, I wasn't aware of cmakeargs feature.

[franksinankaya]

new build command for vfpv3-d16:

./build.sh -cross -arm -cmakeargs -DFEATURE_ARM_FPU_CAPABILITY=0x3 -cmakeargs -DFEATURE_ARM_FPU_TYPE=vfpv3-d16 -cmakeargs -DFEATURE_ARM_FPU_SPEC=1

[jkotas]

Nit: The command line arguments for this do not have to have FEATURE_ prefix. It is odd to call these features.

[franksinankaya]

new build command:

./build.sh -cross -arm -cmakeargs -DARM_FPU_CAPABILITY=0x3 -cmakeargs -DARM_FPU_TYPE=vfpv3-d16

[jkotas]

Looks good to me. @janvorli ?

[janvorli]

LGTM modulo the comments.

[franksinankaya]

new build command:

./build.sh -cross -arm -cmakeargs -DCLR_ARM_FPU_CAPABILITY=0x3 -cmakeargs -DCLR_ARM_FPU_TYPE=vfpv3-d16

[franksinankaya]

any clues on what these failures are? can we retrigger the failing tests?

[jkotas]

This is flaky test. Retriggered.

[franksinankaya]

It looks like it worked.

[BruceForstall]

@franksinankaya Would it be useful to add some comments around your code changes here to explain how to invoke the build to use these new options? E.g., giving the example of

./build.sh -cross -arm -cmakeargs -DCLR_ARM_FPU_CAPABILITY=0x3 -cmakeargs -DCLR_ARM_FPU_TYPE=vfpv3-d16

and explain the bitmask? Or, maybe better, adding a small section to the document https://github.com/dotnet/runtime/blob/master/docs/workflow/building/coreclr/cross-building.md (or perhaps https://github.com/dotnet/runtime/blob/master/docs/workflow/building/coreclr/linux-instructions.md)?

[franksinankaya]

@BruceForstall : Sure, I'll post a follow-up PR