NativeAOT build

[jkotas]

No description provided.

[jkotas]

@MichalStrehovsky I have created the WIP PR here so that we can work on it together. Feel free add more commits to this.

[joperezr]

@jkotas do you want to add CI coverage for this branch? If so, you need to update this with latest dotnet/runtime so that you get the new runtimelab.yml and then just add this branch to the list of branches that triggers builds. If you want me to do that for you let me know.

[jkotas]

@joperezr I have merged latest dotnet/runtime to NativeAOT. Could you please take care of adding the branch name to the right places?

[joperezr]

Sure, I sent out #25 that adds that, feel free to close that one and add that small change right here instead if you prefer that.

[joperezr]

/azp run runtimelab

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[joperezr]

@jkotas do note that since this experiment is compiling native assets, should you need to build additional platforms you can do so by adding the desired platforms to the lists on runtimelab.yml like:

runtimelab/eng/pipelines/runtimelab.yml

Lines 62 to 64 in 4796bd4

	platforms:
	- Linux_x64
	- Windows_NT_x64

The list of platforms we support and you can add are on this file:

https://github.com/dotnet/runtimelab/blob/NativeAOT/eng/pipelines/common/platform-matrix.yml

[jkotas]

@joperezr Thank you for your help with this!

[MichalStrehovsky]

I had to bring back gcinfodecoder for now because including the one from vm requires preprocessor-fu that I haven't reached yet. Directly including from vm brings major confusion around which common.h the include in the decoder refers to. Preprocessor picks the one in vm and bad things happen. I think we'll need to pull that file out of vm.

I got rid of the GC_DIR nicety because it doesn't play with convert_to_absolute_path.

I reordered when nativeaot is included because we probably don't want all of CoreCLR's FEATUREs.

TODO:

• Check we define all necessary defines
• Check we set all necessary compiler switches
• Uncomment AsmOffsets CSPP processing once Runtime.Base is copied over
• Uncomment add_definitions(-DSTRESS_HEAP)
• Get rid of gcinfodecoder copy

I'm working on the first two right now.

[MichalStrehovsky]

Differences in compiler configuration in Release builds:

I guess we're fine with it. We'll see what CFG does.

-     <AdditionalOptions>%(AdditionalOptions) /source-charset:utf-8</AdditionalOptions>
+     <AdditionalOptions>%(AdditionalOptions) /Zc:strictStrings /Zm200 /w34092 /w34121 /w34125 /w34130 /w34132 /w34212 /w34530 /w35038 /w44177 /ZH:SHA_256 /source-charset:utf-8</AdditionalOptions>
      <AssemblerListingLocation>$(IntDir)</AssemblerListingLocation>
      <BufferSecurityCheck>true</BufferSecurityCheck>
      <CompileAs>CompileAsCpp</CompileAs>
+     <ControlFlowGuard>Guard</ControlFlowGuard>
      <DebugInformationFormat>ProgramDatabase</DebugInformationFormat>
+     <DisableSpecificWarnings>4960;4961;4603;4627;4838;4456;4457;4458;4459;4091;4291</DisableSpecificWarnings>      
-     <ExceptionHandling>Sync</ExceptionHandling>
+     <ExceptionHandling>Async</ExceptionHandling>
+     <ForceConformanceInForLoopScope>true</ForceConformanceInForLoopScope>
-     <FloatingPointModel>Precise</FloatingPointModel>
+     <FunctionLevelLinking>true</FunctionLevelLinking>
      <InlineFunctionExpansion>AnySuitable</InlineFunctionExpansion>
+     <IntrinsicFunctions>true</IntrinsicFunctions>
+     <MinimalRebuild>false</MinimalRebuild>
+     <MultiProcessorCompilation>true</MultiProcessorCompilation>
+     <OmitDefaultLibName>true</OmitDefaultLibName>
+     <OmitFramePointers>false</OmitFramePointers>
-     <Optimization>MaxSpeed</Optimization>
+     <Optimization>MinSpace</Optimization>
      <PrecompiledHeader>NotUsing</PrecompiledHeader>
-     <RemoveUnreferencedCodeData>true</RemoveUnreferencedCodeData>
      <RuntimeLibrary>MultiThreaded</RuntimeLibrary>
-     <RuntimeTypeInfo>true</RuntimeTypeInfo>
+     <RuntimeTypeInfo>false</RuntimeTypeInfo>
+     <StringPooling>true</StringPooling>
+     <StructMemberAlignment>8Bytes</StructMemberAlignment>
+     <SuppressStartupBanner>true</SuppressStartupBanner>
+     <TreatSpecificWarningsAsErrors>4640;4007;4013;4102;4551;4700;4806</TreatSpecificWarningsAsErrors>     
      <TreatWChar_tAsBuiltInType>true</TreatWChar_tAsBuiltInType>
+     <TreatWarningAsError>true</TreatWarningAsError>
+     <UndefinePreprocessorDefinitions>_MT</UndefinePreprocessorDefinitions>
      <UseFullPaths>false</UseFullPaths>
-     <WarningLevel>Level1</WarningLevel>
+     <WarningLevel>Level3</WarningLevel>
+     <WholeProgramOptimization>true</WholeProgramOptimization>

[jkotas]

We'll see what CFG does.

Unless we make the code generated by our compiler CFG compliant as well and enable it in the linker, I expect it will just add overhead. From https://docs.microsoft.com/en-us/cpp/build/reference/guard-enable-guard-checks?view=vs-2019: "Code compiled but not linked by using /GUARD:CF incurs the cost of runtime checks, but does not enable CFG protection."

<ExceptionHandling>Async</ExceptionHandling>

We do not want this for CoreRT bits. The async exception handling generates signficantly larger code.

<Optimization>MinSpace</Optimization>

The GC perf may be signficicanly influenced by this one. CoreCLR GC depends on PGO data to turn on MaxSpeed for everything that matters (that is large chunk of GC code). I suspect that optimizing for speed is a better tradeoff for CoreRT without the PGO data since there is not that much else in the native part of runtime. We can keep it as MinSpace and file a tracking perf issue on it.

<RuntimeTypeInfo>false</RuntimeTypeInfo>

Nice! I have not realized that we have RTTI enabled.

<WholeProgramOptimization>true</WholeProgramOptimization>

This will make us sensitive to a match between the compiler version used by the build lab, and linker version used by end user. We can leave it and see whether it causes problems in practice.

I am cleaning up some of this in dotnet/runtime#39901