Implement swift lowering algorithm in Mono's type system

[jkoritzinsky]

This implements the same algorithm as #99438 in the Mono type system.

This doesn't hook the APIs up to any of the codegen backends yet. I still need to figure out the best way to do that (suggestions welcome!).

[lambdageek]

1. generic struct instances aren't MONO_TYPE_VALUETYPE
2. i'm a bit concerned that we'll do a lot of throwaway temporary allocations for pathological cases. I wonder if we can bail out early when we can tell that lowering some struct will result in failure.
3. it seems like some of the complexity here is to handle explicit overlapping layout. Is that the right intuition?

[lambdageek]

Do we really need to account for every byte of the struct, or just the first 4*PointerSize bytes?
Can't we abort this whole algorithm if we're ever certain we're out of room?

Wonder if we can stack alloc this array with a maximum size or else just bail out

[jkoritzinsky]

As of now, 4*PointerSize is the max, but once we have SIMD support, the max goes up drastically (as we could have up to 4 256-byte vectors here).

I'm using a slightly different algorithm in NativeAOT that I could probably use here instead of matching the CoreCLR algorithm that doesn't allocate "struct size" bytes.

[lambdageek]

ah ok. I'm not sure we need a completely different algorithm (I didn't look at the NativeAOT one yet, so I don't know how much work it would entail), just rule out cases that are "obviously too big" - whatever that will mean even with SIMD. i'm particularly (perhaps mistakenly) concerned about InlineArray since it's trivial to make something absolutely massive.

[jkoritzinsky]

1. generic struct instances aren't MONO_TYPE_VALUETYPE

Good to know! I'll update the checks to handle that correctly.

2. i'm a bit concerned that we'll do a lot of throwaway temporary allocations for pathological cases. I wonder if we can bail out early when we can tell that lowering some struct will result in failure.

Yeah, we could put a maximum here for the scenarios we currently support on the "number of bytes" portion of the algorithm.

3. it seems like some of the complexity here is to handle explicit overlapping layout. Is that the right intuition?

Actually, most of the logic here is just to get the lowering right when accounting for padding. Only the logic in set_lowering_range is necessary for explicit layout. It was just easier to write the algorithm to support explicit layout and just do it all right than to add in code blocking it on all platforms (especially as I built the NativeAOT implementation to reuse the same logic as explicit layout validation).

[matouskozak]

Thanks a lot for implementing the Mono support.

I think to handle the lowering, we will need to modify function signature possibly at:

runtime/src/mono/mono/metadata/metadata.c

Line 2638 in 7f4702a

mono_metadata_parse_method_signature_full (MonoImage*m, MonoGenericContainer*container,

I'm not sure if it would be possible to handle this at get_call_info level because the lowering can change number of passed struct fields (e.g., 5-field struct can be lowered to 4 elements). Any other ideas how to connect the Swift struct lowering to the Mono runtime @vargaz@lambdageek ?

Edit. I believe that maybe the handling at call level might be a better approach than modifying the function signature.

[matouskozak]

Why do we need to change the pointer types here? The lowering of MONO_TYPE_PTR and MONO_TYPE_FNPTR is handled further down in this method.

[jkoritzinsky]

We handle it here for pointer fields in structs. The case below only handles on entry (ie when the type passed in is a pointer type).

[matouskozak]

/azp run runtime-extra-platforms

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[matouskozak]

While experimenting with connection this PR to mini codegen I encountered some minor issues with this implementation. However, since this is basically "dead code" at the moment, I will merge this PR and address the issues in subsequent PR.

[jkoritzinsky]

This implements the same algorithm as #99438 in the Mono type system.

This doesn't hook the APIs up to any of the codegen backends yet. I still need to figure out the best way to do that (suggestions welcome!).

[lambdageek]

1. generic struct instances aren't MONO_TYPE_VALUETYPE
2. i'm a bit concerned that we'll do a lot of throwaway temporary allocations for pathological cases. I wonder if we can bail out early when we can tell that lowering some struct will result in failure.
3. it seems like some of the complexity here is to handle explicit overlapping layout. Is that the right intuition?

[lambdageek]

Do we really need to account for every byte of the struct, or just the first 4*PointerSize bytes?
Can't we abort this whole algorithm if we're ever certain we're out of room?

Wonder if we can stack alloc this array with a maximum size or else just bail out

[jkoritzinsky]

As of now, 4*PointerSize is the max, but once we have SIMD support, the max goes up drastically (as we could have up to 4 256-byte vectors here).

I'm using a slightly different algorithm in NativeAOT that I could probably use here instead of matching the CoreCLR algorithm that doesn't allocate "struct size" bytes.

[lambdageek]

ah ok. I'm not sure we need a completely different algorithm (I didn't look at the NativeAOT one yet, so I don't know how much work it would entail), just rule out cases that are "obviously too big" - whatever that will mean even with SIMD. i'm particularly (perhaps mistakenly) concerned about InlineArray since it's trivial to make something absolutely massive.

[jkoritzinsky]

1. generic struct instances aren't MONO_TYPE_VALUETYPE

Good to know! I'll update the checks to handle that correctly.

2. i'm a bit concerned that we'll do a lot of throwaway temporary allocations for pathological cases. I wonder if we can bail out early when we can tell that lowering some struct will result in failure.

Yeah, we could put a maximum here for the scenarios we currently support on the "number of bytes" portion of the algorithm.

3. it seems like some of the complexity here is to handle explicit overlapping layout. Is that the right intuition?

Actually, most of the logic here is just to get the lowering right when accounting for padding. Only the logic in set_lowering_range is necessary for explicit layout. It was just easier to write the algorithm to support explicit layout and just do it all right than to add in code blocking it on all platforms (especially as I built the NativeAOT implementation to reuse the same logic as explicit layout validation).

[matouskozak]

Thanks a lot for implementing the Mono support.

I think to handle the lowering, we will need to modify function signature possibly at:

runtime/src/mono/mono/metadata/metadata.c

Line 2638 in 7f4702a

mono_metadata_parse_method_signature_full (MonoImage*m, MonoGenericContainer*container,

I'm not sure if it would be possible to handle this at get_call_info level because the lowering can change number of passed struct fields (e.g., 5-field struct can be lowered to 4 elements). Any other ideas how to connect the Swift struct lowering to the Mono runtime @vargaz@lambdageek ?

Edit. I believe that maybe the handling at call level might be a better approach than modifying the function signature.

[matouskozak]

Why do we need to change the pointer types here? The lowering of MONO_TYPE_PTR and MONO_TYPE_FNPTR is handled further down in this method.

[jkoritzinsky]

We handle it here for pointer fields in structs. The case below only handles on entry (ie when the type passed in is a pointer type).

[matouskozak]

/azp run runtime-extra-platforms

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[matouskozak]

While experimenting with connection this PR to mini codegen I encountered some minor issues with this implementation. However, since this is basically "dead code" at the moment, I will merge this PR and address the issues in subsequent PR.

[jkoritzinsky]

This implements the same algorithm as #99438 in the Mono type system.

This doesn't hook the APIs up to any of the codegen backends yet. I still need to figure out the best way to do that (suggestions welcome!).

[lambdageek]

1. generic struct instances aren't MONO_TYPE_VALUETYPE
2. i'm a bit concerned that we'll do a lot of throwaway temporary allocations for pathological cases. I wonder if we can bail out early when we can tell that lowering some struct will result in failure.
3. it seems like some of the complexity here is to handle explicit overlapping layout. Is that the right intuition?

[lambdageek]

Do we really need to account for every byte of the struct, or just the first 4*PointerSize bytes?
Can't we abort this whole algorithm if we're ever certain we're out of room?

Wonder if we can stack alloc this array with a maximum size or else just bail out

[jkoritzinsky]

As of now, 4*PointerSize is the max, but once we have SIMD support, the max goes up drastically (as we could have up to 4 256-byte vectors here).

I'm using a slightly different algorithm in NativeAOT that I could probably use here instead of matching the CoreCLR algorithm that doesn't allocate "struct size" bytes.

[lambdageek]

ah ok. I'm not sure we need a completely different algorithm (I didn't look at the NativeAOT one yet, so I don't know how much work it would entail), just rule out cases that are "obviously too big" - whatever that will mean even with SIMD. i'm particularly (perhaps mistakenly) concerned about InlineArray since it's trivial to make something absolutely massive.

[jkoritzinsky]

1. generic struct instances aren't MONO_TYPE_VALUETYPE

Good to know! I'll update the checks to handle that correctly.

2. i'm a bit concerned that we'll do a lot of throwaway temporary allocations for pathological cases. I wonder if we can bail out early when we can tell that lowering some struct will result in failure.

Yeah, we could put a maximum here for the scenarios we currently support on the "number of bytes" portion of the algorithm.

3. it seems like some of the complexity here is to handle explicit overlapping layout. Is that the right intuition?

Actually, most of the logic here is just to get the lowering right when accounting for padding. Only the logic in set_lowering_range is necessary for explicit layout. It was just easier to write the algorithm to support explicit layout and just do it all right than to add in code blocking it on all platforms (especially as I built the NativeAOT implementation to reuse the same logic as explicit layout validation).

[matouskozak]

Thanks a lot for implementing the Mono support.

I think to handle the lowering, we will need to modify function signature possibly at:

runtime/src/mono/mono/metadata/metadata.c

Line 2638 in 7f4702a

mono_metadata_parse_method_signature_full (MonoImage*m, MonoGenericContainer*container,

I'm not sure if it would be possible to handle this at get_call_info level because the lowering can change number of passed struct fields (e.g., 5-field struct can be lowered to 4 elements). Any other ideas how to connect the Swift struct lowering to the Mono runtime @vargaz@lambdageek ?

Edit. I believe that maybe the handling at call level might be a better approach than modifying the function signature.

[matouskozak]

Why do we need to change the pointer types here? The lowering of MONO_TYPE_PTR and MONO_TYPE_FNPTR is handled further down in this method.

[jkoritzinsky]

We handle it here for pointer fields in structs. The case below only handles on entry (ie when the type passed in is a pointer type).

[matouskozak]

/azp run runtime-extra-platforms

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[matouskozak]

While experimenting with connection this PR to mini codegen I encountered some minor issues with this implementation. However, since this is basically "dead code" at the moment, I will merge this PR and address the issues in subsequent PR.

[jkoritzinsky]

This implements the same algorithm as #99438 in the Mono type system.

This doesn't hook the APIs up to any of the codegen backends yet. I still need to figure out the best way to do that (suggestions welcome!).

[lambdageek]

1. generic struct instances aren't MONO_TYPE_VALUETYPE
2. i'm a bit concerned that we'll do a lot of throwaway temporary allocations for pathological cases. I wonder if we can bail out early when we can tell that lowering some struct will result in failure.
3. it seems like some of the complexity here is to handle explicit overlapping layout. Is that the right intuition?

[lambdageek]

Do we really need to account for every byte of the struct, or just the first 4*PointerSize bytes?
Can't we abort this whole algorithm if we're ever certain we're out of room?

Wonder if we can stack alloc this array with a maximum size or else just bail out

[jkoritzinsky]

As of now, 4*PointerSize is the max, but once we have SIMD support, the max goes up drastically (as we could have up to 4 256-byte vectors here).

I'm using a slightly different algorithm in NativeAOT that I could probably use here instead of matching the CoreCLR algorithm that doesn't allocate "struct size" bytes.

[lambdageek]

ah ok. I'm not sure we need a completely different algorithm (I didn't look at the NativeAOT one yet, so I don't know how much work it would entail), just rule out cases that are "obviously too big" - whatever that will mean even with SIMD. i'm particularly (perhaps mistakenly) concerned about InlineArray since it's trivial to make something absolutely massive.

[jkoritzinsky]

1. generic struct instances aren't MONO_TYPE_VALUETYPE

Good to know! I'll update the checks to handle that correctly.

2. i'm a bit concerned that we'll do a lot of throwaway temporary allocations for pathological cases. I wonder if we can bail out early when we can tell that lowering some struct will result in failure.

Yeah, we could put a maximum here for the scenarios we currently support on the "number of bytes" portion of the algorithm.

3. it seems like some of the complexity here is to handle explicit overlapping layout. Is that the right intuition?

Actually, most of the logic here is just to get the lowering right when accounting for padding. Only the logic in set_lowering_range is necessary for explicit layout. It was just easier to write the algorithm to support explicit layout and just do it all right than to add in code blocking it on all platforms (especially as I built the NativeAOT implementation to reuse the same logic as explicit layout validation).

[matouskozak]

Thanks a lot for implementing the Mono support.

I think to handle the lowering, we will need to modify function signature possibly at:

runtime/src/mono/mono/metadata/metadata.c

Line 2638 in 7f4702a

mono_metadata_parse_method_signature_full (MonoImage*m, MonoGenericContainer*container,

I'm not sure if it would be possible to handle this at get_call_info level because the lowering can change number of passed struct fields (e.g., 5-field struct can be lowered to 4 elements). Any other ideas how to connect the Swift struct lowering to the Mono runtime @vargaz@lambdageek ?

Edit. I believe that maybe the handling at call level might be a better approach than modifying the function signature.

[matouskozak]

Why do we need to change the pointer types here? The lowering of MONO_TYPE_PTR and MONO_TYPE_FNPTR is handled further down in this method.

[jkoritzinsky]

We handle it here for pointer fields in structs. The case below only handles on entry (ie when the type passed in is a pointer type).

[matouskozak]

/azp run runtime-extra-platforms

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[matouskozak]

While experimenting with connection this PR to mini codegen I encountered some minor issues with this implementation. However, since this is basically "dead code" at the moment, I will merge this PR and address the issues in subsequent PR.

[jkoritzinsky]

This implements the same algorithm as #99438 in the Mono type system.

This doesn't hook the APIs up to any of the codegen backends yet. I still need to figure out the best way to do that (suggestions welcome!).

[lambdageek]

1. generic struct instances aren't MONO_TYPE_VALUETYPE
2. i'm a bit concerned that we'll do a lot of throwaway temporary allocations for pathological cases. I wonder if we can bail out early when we can tell that lowering some struct will result in failure.
3. it seems like some of the complexity here is to handle explicit overlapping layout. Is that the right intuition?

[lambdageek]

Do we really need to account for every byte of the struct, or just the first 4*PointerSize bytes?
Can't we abort this whole algorithm if we're ever certain we're out of room?

Wonder if we can stack alloc this array with a maximum size or else just bail out

[jkoritzinsky]

As of now, 4*PointerSize is the max, but once we have SIMD support, the max goes up drastically (as we could have up to 4 256-byte vectors here).

I'm using a slightly different algorithm in NativeAOT that I could probably use here instead of matching the CoreCLR algorithm that doesn't allocate "struct size" bytes.

[lambdageek]

ah ok. I'm not sure we need a completely different algorithm (I didn't look at the NativeAOT one yet, so I don't know how much work it would entail), just rule out cases that are "obviously too big" - whatever that will mean even with SIMD. i'm particularly (perhaps mistakenly) concerned about InlineArray since it's trivial to make something absolutely massive.

[jkoritzinsky]

1. generic struct instances aren't MONO_TYPE_VALUETYPE

Good to know! I'll update the checks to handle that correctly.

2. i'm a bit concerned that we'll do a lot of throwaway temporary allocations for pathological cases. I wonder if we can bail out early when we can tell that lowering some struct will result in failure.

Yeah, we could put a maximum here for the scenarios we currently support on the "number of bytes" portion of the algorithm.

3. it seems like some of the complexity here is to handle explicit overlapping layout. Is that the right intuition?

Actually, most of the logic here is just to get the lowering right when accounting for padding. Only the logic in set_lowering_range is necessary for explicit layout. It was just easier to write the algorithm to support explicit layout and just do it all right than to add in code blocking it on all platforms (especially as I built the NativeAOT implementation to reuse the same logic as explicit layout validation).

[matouskozak]

Thanks a lot for implementing the Mono support.

I think to handle the lowering, we will need to modify function signature possibly at:

runtime/src/mono/mono/metadata/metadata.c

Line 2638 in 7f4702a

mono_metadata_parse_method_signature_full (MonoImage*m, MonoGenericContainer*container,

I'm not sure if it would be possible to handle this at get_call_info level because the lowering can change number of passed struct fields (e.g., 5-field struct can be lowered to 4 elements). Any other ideas how to connect the Swift struct lowering to the Mono runtime @vargaz@lambdageek ?

Edit. I believe that maybe the handling at call level might be a better approach than modifying the function signature.

[matouskozak]

Why do we need to change the pointer types here? The lowering of MONO_TYPE_PTR and MONO_TYPE_FNPTR is handled further down in this method.

[jkoritzinsky]

We handle it here for pointer fields in structs. The case below only handles on entry (ie when the type passed in is a pointer type).

[matouskozak]

/azp run runtime-extra-platforms

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[matouskozak]

While experimenting with connection this PR to mini codegen I encountered some minor issues with this implementation. However, since this is basically "dead code" at the moment, I will merge this PR and address the issues in subsequent PR.

[jkoritzinsky]

This implements the same algorithm as #99438 in the Mono type system.

This doesn't hook the APIs up to any of the codegen backends yet. I still need to figure out the best way to do that (suggestions welcome!).

[lambdageek]

1. generic struct instances aren't MONO_TYPE_VALUETYPE
2. i'm a bit concerned that we'll do a lot of throwaway temporary allocations for pathological cases. I wonder if we can bail out early when we can tell that lowering some struct will result in failure.
3. it seems like some of the complexity here is to handle explicit overlapping layout. Is that the right intuition?

[lambdageek]

Do we really need to account for every byte of the struct, or just the first 4*PointerSize bytes?
Can't we abort this whole algorithm if we're ever certain we're out of room?

Wonder if we can stack alloc this array with a maximum size or else just bail out

[jkoritzinsky]

As of now, 4*PointerSize is the max, but once we have SIMD support, the max goes up drastically (as we could have up to 4 256-byte vectors here).

I'm using a slightly different algorithm in NativeAOT that I could probably use here instead of matching the CoreCLR algorithm that doesn't allocate "struct size" bytes.

[lambdageek]

ah ok. I'm not sure we need a completely different algorithm (I didn't look at the NativeAOT one yet, so I don't know how much work it would entail), just rule out cases that are "obviously too big" - whatever that will mean even with SIMD. i'm particularly (perhaps mistakenly) concerned about InlineArray since it's trivial to make something absolutely massive.

[jkoritzinsky]

1. generic struct instances aren't MONO_TYPE_VALUETYPE

Good to know! I'll update the checks to handle that correctly.

2. i'm a bit concerned that we'll do a lot of throwaway temporary allocations for pathological cases. I wonder if we can bail out early when we can tell that lowering some struct will result in failure.

Yeah, we could put a maximum here for the scenarios we currently support on the "number of bytes" portion of the algorithm.

3. it seems like some of the complexity here is to handle explicit overlapping layout. Is that the right intuition?

Actually, most of the logic here is just to get the lowering right when accounting for padding. Only the logic in set_lowering_range is necessary for explicit layout. It was just easier to write the algorithm to support explicit layout and just do it all right than to add in code blocking it on all platforms (especially as I built the NativeAOT implementation to reuse the same logic as explicit layout validation).

[matouskozak]

Thanks a lot for implementing the Mono support.

I think to handle the lowering, we will need to modify function signature possibly at:

runtime/src/mono/mono/metadata/metadata.c

Line 2638 in 7f4702a

mono_metadata_parse_method_signature_full (MonoImage*m, MonoGenericContainer*container,

I'm not sure if it would be possible to handle this at get_call_info level because the lowering can change number of passed struct fields (e.g., 5-field struct can be lowered to 4 elements). Any other ideas how to connect the Swift struct lowering to the Mono runtime @vargaz@lambdageek ?

Edit. I believe that maybe the handling at call level might be a better approach than modifying the function signature.

[matouskozak]

Why do we need to change the pointer types here? The lowering of MONO_TYPE_PTR and MONO_TYPE_FNPTR is handled further down in this method.

[jkoritzinsky]

We handle it here for pointer fields in structs. The case below only handles on entry (ie when the type passed in is a pointer type).

[matouskozak]

/azp run runtime-extra-platforms

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[matouskozak]

While experimenting with connection this PR to mini codegen I encountered some minor issues with this implementation. However, since this is basically "dead code" at the moment, I will merge this PR and address the issues in subsequent PR.

[jkoritzinsky]

This implements the same algorithm as #99438 in the Mono type system.

This doesn't hook the APIs up to any of the codegen backends yet. I still need to figure out the best way to do that (suggestions welcome!).

[lambdageek]

1. generic struct instances aren't MONO_TYPE_VALUETYPE
2. i'm a bit concerned that we'll do a lot of throwaway temporary allocations for pathological cases. I wonder if we can bail out early when we can tell that lowering some struct will result in failure.
3. it seems like some of the complexity here is to handle explicit overlapping layout. Is that the right intuition?

[lambdageek]

Do we really need to account for every byte of the struct, or just the first 4*PointerSize bytes?
Can't we abort this whole algorithm if we're ever certain we're out of room?

Wonder if we can stack alloc this array with a maximum size or else just bail out

[jkoritzinsky]

As of now, 4*PointerSize is the max, but once we have SIMD support, the max goes up drastically (as we could have up to 4 256-byte vectors here).

I'm using a slightly different algorithm in NativeAOT that I could probably use here instead of matching the CoreCLR algorithm that doesn't allocate "struct size" bytes.

[lambdageek]

ah ok. I'm not sure we need a completely different algorithm (I didn't look at the NativeAOT one yet, so I don't know how much work it would entail), just rule out cases that are "obviously too big" - whatever that will mean even with SIMD. i'm particularly (perhaps mistakenly) concerned about InlineArray since it's trivial to make something absolutely massive.

[jkoritzinsky]

1. generic struct instances aren't MONO_TYPE_VALUETYPE

Good to know! I'll update the checks to handle that correctly.

2. i'm a bit concerned that we'll do a lot of throwaway temporary allocations for pathological cases. I wonder if we can bail out early when we can tell that lowering some struct will result in failure.

Yeah, we could put a maximum here for the scenarios we currently support on the "number of bytes" portion of the algorithm.

3. it seems like some of the complexity here is to handle explicit overlapping layout. Is that the right intuition?

Actually, most of the logic here is just to get the lowering right when accounting for padding. Only the logic in set_lowering_range is necessary for explicit layout. It was just easier to write the algorithm to support explicit layout and just do it all right than to add in code blocking it on all platforms (especially as I built the NativeAOT implementation to reuse the same logic as explicit layout validation).

[matouskozak]

Thanks a lot for implementing the Mono support.

I think to handle the lowering, we will need to modify function signature possibly at:

runtime/src/mono/mono/metadata/metadata.c

Line 2638 in 7f4702a

mono_metadata_parse_method_signature_full (MonoImage*m, MonoGenericContainer*container,

I'm not sure if it would be possible to handle this at get_call_info level because the lowering can change number of passed struct fields (e.g., 5-field struct can be lowered to 4 elements). Any other ideas how to connect the Swift struct lowering to the Mono runtime @vargaz@lambdageek ?

Edit. I believe that maybe the handling at call level might be a better approach than modifying the function signature.

[matouskozak]

Why do we need to change the pointer types here? The lowering of MONO_TYPE_PTR and MONO_TYPE_FNPTR is handled further down in this method.

[jkoritzinsky]

We handle it here for pointer fields in structs. The case below only handles on entry (ie when the type passed in is a pointer type).

[matouskozak]

/azp run runtime-extra-platforms

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[matouskozak]

While experimenting with connection this PR to mini codegen I encountered some minor issues with this implementation. However, since this is basically "dead code" at the moment, I will merge this PR and address the issues in subsequent PR.

[jkoritzinsky]

This implements the same algorithm as #99438 in the Mono type system.

This doesn't hook the APIs up to any of the codegen backends yet. I still need to figure out the best way to do that (suggestions welcome!).

[lambdageek]

1. generic struct instances aren't MONO_TYPE_VALUETYPE
2. i'm a bit concerned that we'll do a lot of throwaway temporary allocations for pathological cases. I wonder if we can bail out early when we can tell that lowering some struct will result in failure.
3. it seems like some of the complexity here is to handle explicit overlapping layout. Is that the right intuition?

[lambdageek]

Do we really need to account for every byte of the struct, or just the first 4*PointerSize bytes?
Can't we abort this whole algorithm if we're ever certain we're out of room?

Wonder if we can stack alloc this array with a maximum size or else just bail out

[jkoritzinsky]

As of now, 4*PointerSize is the max, but once we have SIMD support, the max goes up drastically (as we could have up to 4 256-byte vectors here).

I'm using a slightly different algorithm in NativeAOT that I could probably use here instead of matching the CoreCLR algorithm that doesn't allocate "struct size" bytes.

[lambdageek]

ah ok. I'm not sure we need a completely different algorithm (I didn't look at the NativeAOT one yet, so I don't know how much work it would entail), just rule out cases that are "obviously too big" - whatever that will mean even with SIMD. i'm particularly (perhaps mistakenly) concerned about InlineArray since it's trivial to make something absolutely massive.

[jkoritzinsky]

1. generic struct instances aren't MONO_TYPE_VALUETYPE

Good to know! I'll update the checks to handle that correctly.

2. i'm a bit concerned that we'll do a lot of throwaway temporary allocations for pathological cases. I wonder if we can bail out early when we can tell that lowering some struct will result in failure.

Yeah, we could put a maximum here for the scenarios we currently support on the "number of bytes" portion of the algorithm.

3. it seems like some of the complexity here is to handle explicit overlapping layout. Is that the right intuition?

Actually, most of the logic here is just to get the lowering right when accounting for padding. Only the logic in set_lowering_range is necessary for explicit layout. It was just easier to write the algorithm to support explicit layout and just do it all right than to add in code blocking it on all platforms (especially as I built the NativeAOT implementation to reuse the same logic as explicit layout validation).

[matouskozak]

Thanks a lot for implementing the Mono support.

I think to handle the lowering, we will need to modify function signature possibly at:

runtime/src/mono/mono/metadata/metadata.c

Line 2638 in 7f4702a

mono_metadata_parse_method_signature_full (MonoImage*m, MonoGenericContainer*container,

I'm not sure if it would be possible to handle this at get_call_info level because the lowering can change number of passed struct fields (e.g., 5-field struct can be lowered to 4 elements). Any other ideas how to connect the Swift struct lowering to the Mono runtime @vargaz@lambdageek ?

Edit. I believe that maybe the handling at call level might be a better approach than modifying the function signature.

[matouskozak]

Why do we need to change the pointer types here? The lowering of MONO_TYPE_PTR and MONO_TYPE_FNPTR is handled further down in this method.

[jkoritzinsky]

We handle it here for pointer fields in structs. The case below only handles on entry (ie when the type passed in is a pointer type).

[matouskozak]

/azp run runtime-extra-platforms

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[matouskozak]

While experimenting with connection this PR to mini codegen I encountered some minor issues with this implementation. However, since this is basically "dead code" at the moment, I will merge this PR and address the issues in subsequent PR.