Compile NativeAOT on x86 #1531

kant2002 · 2021-09-08T06:03:55Z

Thanks to suggestions from dotnet/runtime#86573 I was able to compile NativeAOT on Windows x86.
I apply just USE_GC_INFO_DECODER for now.

kant2002 · 2021-09-08T09:52:49Z

I need to uncomment parts of

runtimelab/src/coreclr/nativeaot/Runtime/i386/WriteBarriers.asm

Lines 223 to 236 in 67927bd

 ;; Need some more write barriers to run CLR compiled MDIL on Redhawk - commented out for now 

 ;; DEFINE_WRITE_BARRIER EDX, EAX 

 ;; DEFINE_WRITE_BARRIER EDX, ECX 

 ;; DEFINE_WRITE_BARRIER EDX, EBX 

 ;; DEFINE_WRITE_BARRIER EDX, ESI 

 ;; DEFINE_WRITE_BARRIER EDX, EDI 

 ;; DEFINE_WRITE_BARRIER EDX, EBP 

 ;; DEFINE_CHECKED_WRITE_BARRIER EDX, EAX 

 ;; DEFINE_CHECKED_WRITE_BARRIER EDX, ECX 

 ;; DEFINE_CHECKED_WRITE_BARRIER EDX, EBX 

 ;; DEFINE_CHECKED_WRITE_BARRIER EDX, ESI 

 ;; DEFINE_CHECKED_WRITE_BARRIER EDX, EDI 

 ;; DEFINE_CHECKED_WRITE_BARRIER EDX, EBP

But still ILC fails to process CORINFO_HELP_ENDCATCH. I would need advice where I can take parts for that implementation in ASM or somewhere elese.

kant2002 · 2021-09-08T09:54:56Z

Also do I send something like #1530 and #1509 so I would not think too much about ObjWriter?

jkotas · 2021-09-08T14:37:03Z

src/coreclr/nativeaot/Runtime/gcinfodecoder.h

@@ -1,4 +1,7 @@
 // Licensed to the .NET Foundation under one or more agreements.
 // The .NET Foundation licenses this file to you under the MIT license.

+// USE_GC_INFO_DECODER does not defined for Win-x86 in CoreCLR


This won't be enough. You will also need to define it when building RyuJIT.

I assume this is NativeAOT specific customization to https://github.com/dotnet/runtimelab/blob/feature/NativeAOT/src/coreclr/jit/CMakeLists.txt

Also I did not see any reference to USE_GC_INFO_DECODER in jit folder. Are you talking that I need to use FEATURE_EH_FUNCLETS then how I make that change purely NativeAOT specific ?

I assume this is NativeAOT specific customization to https://github.com/dotnet/runtimelab/blob/feature/NativeAOT/src/coreclr/jit/CMakeLists.txt

Yes. It becomes tricky because it would mean that the JIT binary used by CoreCLR will be different from the JIT binary used by AOT. It is actually a bunch of binaries since we build multiple variants to support cross-compilation. There are short-term hacks possible in this branch. Once/if we move NativeAOT to dotnet/runtime, we will need to be able to use the same JIT binary for both regular CoreCLR and NativeAOT. If we keep the ABI differences, we may need to replace the ifdefs with dynamic checks in the JIT. Other option is to just stick with the same ABI as CoreCLR and clean it up as necessary (ie avoid forking the ABI for NativeAOT).

Also I did not see any reference to USE_GC_INFO_DECODER in jit folder

JIT has JIT32_GCENCODER. JIT32_GCENCODER = !USE_GC_INFO_DECODER

I think I found a way how we can postpone decision temporary. Instead of this particular change, I remove these lines from .h files

runtimelab/src/coreclr/jit/jit.h

Lines 468 to 470 in 6f2cfcd

#ifdef TARGET_X86

#define JIT32_GCENCODER

#endif

and

runtimelab/src/coreclr/inc/gcinfodecoder.h

Lines 22 to 24 in 6f2cfcd

#if !defined(TARGET_X86)

#define USE_GC_INFO_DECODER

#endif

And will control these defines from CMake files. That change maybe be submitted to Runtime repo I think, and all hacks would be in CMake files in NativeAOT repo. That way we can explore all 3 options without too much commitment to either of them, if I only apply CMake hacks locally. What do you think?

I do not think that there is a big difference in controlling it in cmake files vs. in header files. Both of these are short-term hacks that would be ok in this branch, but not in dotnet/runtime. You end up with a JIT build that is different from regular CoreCLR JIT build in either case.

Ok, will try that. I think about JIT as black box for now, so it was a scary change for me. I think I understand direction now.

jkotas · 2021-09-08T14:44:25Z

src/coreclr/nativeaot/Runtime/windows/PalRedhawkCommon.cpp

@@ -172,7 +172,7 @@ REDHAWK_PALEXPORT int32_t PalGetModuleFileName(_Out_ const TCHAR** pModuleNameOu
 return 0;
 }

-REDHAWK_PALEXPORT uint64_t __cdecl PalGetTickCount64()
+REDHAWK_PALEXPORT uint64_t REDHAWK_PALAPI PalGetTickCount64()


PalGetTickCount64 is defined as cdecl in C#. It has to match.

REDHAWK_PALAPI defined as StdCall on non-Unix, and empty value on Unix. Does this mean, that I should change to StdCall in C#?

You can add new RhpGetTickCount64 that is cdecl and call that from C# instead of PalGetTickCount64. And then this change can stay.

So you propose declare RhpGetTickCount64 in c++, for which I would add corresponding C# function, and use that function instead of PalGetTickCount64? I probably can just define __cdecl to nothing for TARGET_X86 in that file then.

Yes. There is number of methods like that (e.g. RhpReleaseCastCacheLock). They are using __cdecl already.

jkotas · 2021-09-08T14:47:19Z

...lr/nativeaot/System.Private.TypeLoader/src/Internal/Runtime/TypeLoader/CallConverterThunk.cs

 #if CALLDESCR_FPARGREGSARERETURNREGS
+ out CommonInputThunkStub
 #else


I do not see why this change is needed.

This is purely to satisfy style cop. I may suppress it on these code. It did not like comma before other parameters.

Suppressing the warning would be better. The ifdefs do not make logical sense with this change.

jkotas · 2021-09-08T15:00:48Z

Also do I send something like #1530 and #1509 so I would not think too much about ObjWriter?

I would not want to add x86 to the official builds until it is close to working.

jkotas · 2021-09-08T15:12:46Z

CORINFO_HELP_ENDCATCH

This helper is only needed for !FEATURE_EH_FUNCLETS. If you plan to go with FEATURE_EH_FUNCLETS, it won't be needed.

kant2002 · 2021-09-09T09:46:00Z

There bunch of assertions with only 2 kinds of them during ILC run with latest changes. Not sure if this is indication that I have to do something extra, or this is indication that I do something wrong

runtimelab/src/coreclr/jit/gcencode.cpp

Line 4594 in 6f2cfcd

assert(genRegPtrTemp->rpdGCtypeGet() != GCT_NONE);

and

runtimelab/src/coreclr/gcinfo/gcinfoencoder.cpp

Line 1158 in 6f2cfcd

_ASSERTE( m_SizeOfStackOutgoingAndScratchArea != (UINT32)-1 );

Last one has additional information in form of this text message Assertion failed 'genRegPtrTemp->rpdGCtypeGet() != GCT_NONE' in 'System.IO.StreamWriter:.cctor()' during 'Emit GC+EH tables' (IL size 27)

kant2002 · 2021-09-09T12:43:30Z

At least

runtimelab/src/coreclr/gcinfo/gcinfoencoder.cpp

Line 1158 in 6f2cfcd

_ASSERTE( m_SizeOfStackOutgoingAndScratchArea != (UINT32)-1 );

related to #define FEATURE_FIXED_OUT_ARGS 0 on x86.
If I define #define FEATURE_FIXED_OUT_ARGS 1 on x86.
next assertion is

runtimelab/src/coreclr/jit/lower.cpp

Line 1204 in 6f2cfcd

assert(arg->TypeGet() != TYP_STRUCT);

Which seems to be related to FEATURE_PUT_STRUCT_ARG_STK being defined. If I undefine it for Win-x86 configuration, then src\coreclr\jit\codegenxarch.cpp does not ready for this challenge now. I was try to add missing #ifdefs but next issues start appear in src\coreclr\jit\lowerxarch.cpp and I think rabbit hole is too deep. Maybe I miss something simple

kant2002 · 2021-09-20T14:28:49Z

Let's start with IL

IL to import:
IL_0000  16                ldc.i4.0    
IL_0001  6a                conv.i8     
IL_0002  7e 23 04 00 04    ldsfld       0x4000423
IL_0007  73 37 0a 00 06    newobj       0x6000A37
IL_000c  80 9d 01 00 04    stsfld       0x400019D

Which translated to following statements

***** BB01
STMT00001 (IL   ???...  ???)
               [000011] I-CXG-------              *  CALL      void   System.DateTimeOffset..ctor (exactContextHnd=0x4000000000420029)
               [000010] ------------ this in ecx  +--*  ADDR      byref 
               [000009] -------N----              |  \--*  LCL_VAR   struct<System.DateTimeOffset, 12> V01 tmp1         
               [000001] ------------ arg1         +--*  CNS_LNG   long   0x0000000000000000
               [000005] --CXG------- arg2         \--*  OBJ       struct<System.TimeSpan, 8>
               [000004] --CXG-------                 \--*  ADD       byref 
               [000002] H-CXG-------                    +--*  CALL help byref  HELPER.CORINFO_HELP_READYTORUN_STATIC_BASE
               [000003] ------------                    \--*  CNS_INT   int    0 Fseq[Zero]

***** BB01
STMT00002 (IL 0x00C...  ???)
               [000018] -ACXG-------              *  ASG       struct (copy)
               [000017] --CXG-------              +--*  BLK       struct<System.DateTimeOffset, 12>
               [000015] --CXG-------              |  \--*  ADD       byref 
               [000013] H-CXG-------              |     +--*  CALL help byref  HELPER.CORINFO_HELP_READYTORUN_STATIC_BASE
               [000014] ------------              |     \--*  CNS_INT   int    0 Fseq[MinValue]
               [000012] ------------              \--*  LCL_VAR   struct<System.DateTimeOffset, 12> V01 tmp1

Eventually it transformed to

***** BB01
STMT00000 (IL 0x000...0x00C)
N003 (  5,  4) [000008] IA--G---R---              *  ASG       struct (init) $VN.Void
N002 (  3,  2) [000006] D---G--N----              +--*  LCL_VAR   struct<System.DateTimeOffset, 12>(AX) V01 tmp1         
N001 (  1,  1) [000007] ------------              \--*  CNS_INT   int    0 $41

***** BB01
STMT00001 (IL   ???...  ???)
N014 ( 47, 27) [000011] -ACXG-------               *  CALL      void   System.DateTimeOffset..ctor $VN.Void
N010 ( 22, 11) [000058] -ACXG---R-L- arg2 SETUP    +--*  ASG       struct (copy) $VN.Void
N009 (  3,  2) [000056] D------N----               |  +--*  LCL_VAR   struct<System.TimeSpan, 8> V04 tmp4         d:1
N008 ( 18,  8) [000005] -ACXG--N----               |  \--*  IND       struct <l:$285, c:$284>
N007 ( 15,  6) [000077] -ACXG-------               |     \--*  COMMA     byref  $240
N005 ( 14,  5) [000075] -ACXG---R---               |        +--*  ASG       byref  $VN.Void
N004 (  1,  1) [000074] D------N----               |        |  +--*  LCL_VAR   byref  V07 cse0         d:1 $240
N003 ( 14,  5) [000002] H-CXG-------               |        |  \--*  CALL help byref  HELPER.CORINFO_HELP_READYTORUN_STATIC_BASE Zero Fseq[Zero] $240
N006 (  1,  1) [000076] ------------               |        \--*  LCL_VAR   byref  V07 cse0         u:1 Zero Fseq[Zero] $240
N011 (  3,  2) [000059] ------------ arg2 in out+08+--*  LCL_VAR   struct<System.TimeSpan, 8> V04 tmp4         u:1 (last use) $2c2
N012 (  3,  3) [000010] ------------ this in ecx   +--*  LCL_VAR_ADDR byref  V01 tmp1          $102
N013 (  2,  2) [000001] ------------ arg1 in out+00\--*  CNS_LNG   long   0x0000000000000000 $300

And this is last state of this part of tree before it start asserting. I mark argument which lowering complains about.

lowering call (before):
N006 (  1,  1) [000076] ------------        t76 =    LCL_VAR   byref  V07 cse0         u:1 Zero Fseq[Zero] $240
                                                  /--*  t76    byref  
N008 ( 18,  8) [000005] -c-XG--N----         t5 = *  IND       struct <l:$285, c:$284>
               [000100] Dc-----N----       t100 =    LCL_VAR_ADDR byref  V04 tmp4         
                                                  /--*  t100   byref  
                                                  +--*  t5     struct 
N010 ( 22, 11) [000058] sA--------L-              *  STORE_BLK struct<System.TimeSpan, 8> (copy) (Unroll)
N011 (  3,  2) [000059] ------------        t59 =    LCL_VAR   struct<System.TimeSpan, 8> V04 tmp4         u:1 (last use) $2c2
N012 (  3,  3) [000010] ------------        t10 =    LCL_VAR_ADDR byref  V01 tmp1          $102
N013 (  2,  2) [000001] ------------         t1 =    CNS_INT   int    0
               [000093] ------------        t93 =    CNS_INT   int    0
                                                  /--*  t1     int    
                                                  +--*  t93    int    
               [000094] ------------        t94 = *  LONG      long  
                                                  /--*  t59    struct arg2 in out+08  <-- !!!!!  ASSERT ON THIS ARG !!!!!
                                                  +--*  t10    byref  this in ecx
                                                  +--*  t94    long   arg1 in out+00
N014 ( 47, 27) [000011] --CXG-------              *  CALL      void   System.DateTimeOffset..ctor $VN.Void

My understanding that assert do not like that "local variable" passed as struct, and this should be "morphed" earlier. If morphing is indeed proper place for turning structs into I will look there. I also will re-read responsibilities of each phase, so maybe I will get better understanding what's going on.

unofficialdev · 2021-11-27T03:58:22Z

Has this pull request been merged into the master branch?

kant2002 · 2021-11-27T04:00:59Z

@unofficialdev I was stuck with that. I do not have enough cycles to make that work properly, as such this is only half done. I still have appetite for that, just delay this excercise. If you want to pursue, you are free base that on current work,

This is retrofitting parts of dotnet/runtimelab#1531

jkotas · 2022-02-01T14:31:49Z

This work should continue in dotnet/runtime repo.

yowl · 2022-12-12T01:00:17Z

Why was RhpGetTickCount64 added as void not uint64_t ? wasm-ld doesn't like the mismatch between the c# declaration in InternalCalls.cs of ulong .

jkotas · 2022-12-12T02:12:57Z

It was an oversight. Would you like to submit a PR with a fix?

yowl · 2022-12-12T12:48:21Z

Thanks: dotnet/runtime#79538

dadavadd · 2024-04-18T05:34:33Z

Could you tell us how you were able to achieve NativeAOT compilation in x86? I want to link a C++ static library to my x86 project.

yowl · 2024-04-18T12:05:28Z

Could you tell us how you were able to achieve NativeAOT compilation in x86? I want to link a C++ static library to my x86 project.

Hi, work for x86 continues in the runtime repo, not here in runtimelab.

jkotas reviewed Sep 8, 2021

View reviewed changes

kant2002 added 9 commits December 29, 2021 09:22

Compile NativeAOT on x86

6fc143f

Fix compilation error

ea085f4

Add missing define

8db4a19

Please style conventions

7c40486

Process R2R helpers

b9dabe3

Apply suggestion from code review

5241a38

Add RhpGetTickCount64 with __cdecl call conv

cb65d00

Enable FEATURE_EH_FUNCLETS and USE_GC_INFO_DECODER for x86

fd692d6

Remove debug code

3c12c4b

kant2002 force-pushed the kant/x86-support branch from 3906cb0 to 3c12c4b Compare December 29, 2021 03:23

kant2002 added a commit to kant2002/runtime that referenced this pull request Dec 29, 2021

Cleanup in NativeAOT from x86 attempt

178f40a

This is retrofitting parts of dotnet/runtimelab#1531

kant2002 mentioned this pull request Dec 29, 2021

Cleanup in NativeAOT from x86 attempt dotnet/runtime#63182

Merged

jkotas pushed a commit to dotnet/runtime that referenced this pull request Dec 30, 2021

Cleanup in NativeAOT from x86 attempt (#63182)

e4e4cb6

This is retrofitting parts of dotnet/runtimelab#1531

jkotas closed this Feb 1, 2022

hez2010 mentioned this pull request Nov 26, 2023

Uuuh I caught linux-x86 on dotnet 7.0 dotnet/runtime#95240

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Compile NativeAOT on x86 #1531

Compile NativeAOT on x86 #1531

kant2002 commented Sep 8, 2021

kant2002 commented Sep 8, 2021

kant2002 commented Sep 8, 2021

jkotas Sep 8, 2021

kant2002 Sep 8, 2021

jkotas Sep 8, 2021

kant2002 Sep 8, 2021

jkotas Sep 8, 2021

kant2002 Sep 8, 2021

jkotas Sep 8, 2021

kant2002 Sep 8, 2021

jkotas Sep 8, 2021

kant2002 Sep 8, 2021

jkotas Sep 8, 2021

jkotas Sep 8, 2021

kant2002 Sep 8, 2021

jkotas Sep 8, 2021

jkotas commented Sep 8, 2021

jkotas commented Sep 8, 2021

kant2002 commented Sep 9, 2021

kant2002 commented Sep 9, 2021 •

edited

Loading

kant2002 commented Sep 20, 2021

unofficialdev commented Nov 27, 2021

kant2002 commented Nov 27, 2021

jkotas commented Feb 1, 2022

yowl commented Dec 12, 2022

jkotas commented Dec 12, 2022

yowl commented Dec 12, 2022

dadavadd commented Apr 18, 2024 •

edited

Loading

yowl commented Apr 18, 2024

Compile NativeAOT on x86 #1531

Compile NativeAOT on x86 #1531

Conversation

kant2002 commented Sep 8, 2021

kant2002 commented Sep 8, 2021

kant2002 commented Sep 8, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jkotas commented Sep 8, 2021

jkotas commented Sep 8, 2021

kant2002 commented Sep 9, 2021

kant2002 commented Sep 9, 2021 • edited Loading

kant2002 commented Sep 20, 2021

unofficialdev commented Nov 27, 2021

kant2002 commented Nov 27, 2021

jkotas commented Feb 1, 2022

yowl commented Dec 12, 2022

jkotas commented Dec 12, 2022

yowl commented Dec 12, 2022

dadavadd commented Apr 18, 2024 • edited Loading

yowl commented Apr 18, 2024

kant2002 commented Sep 9, 2021 •

edited

Loading

dadavadd commented Apr 18, 2024 •

edited

Loading