Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fold full-width SIMD-typed indirections #76745

Merged
merged 4 commits into from
Oct 31, 2022

Conversation

SingleAccretion
Copy link
Contributor

@SingleAccretion SingleAccretion commented Oct 7, 2022

I. e. OBJ/IND<simd>(ADDR(LCL_VAR<simd>)).

Some positive (in nature) diffs, with a TP win as well.

@dotnet-issue-labeler dotnet-issue-labeler bot added the area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI label Oct 7, 2022
@ghost ghost added the community-contribution Indicates that the PR has been added by a community member label Oct 7, 2022
@ghost
Copy link

ghost commented Oct 7, 2022

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch
See info in area-owners.md if you want to be subscribed.

Issue Details

I. e. OBJ/IND<simd>(ADDR(LCL_VAR<simd>)). We're expecting minor positive diffs.

Author: SingleAccretion
Assignees: -
Labels:

area-CodeGen-coreclr

Milestone: -

@SingleAccretion SingleAccretion marked this pull request as ready for review October 7, 2022 18:39
@SingleAccretion
Copy link
Contributor Author

@dotnet/jit-contrib

We're getting close to completing the "fold all indirect access in local morph" part of the ADDR work.

@EgorBo
Copy link
Member

EgorBo commented Oct 7, 2022

positive diffs

doesn't sound good 😄 luckily, they're negative in fact!

@EgorBo
Copy link
Member

EgorBo commented Oct 7, 2022

Do you want to run some outerloop here? Since over the last few weeks it was constantly in a bad shape we try to run them in all potentially impactful PRs explicitly

@SingleAccretion
Copy link
Contributor Author

Do you want to run some outerloop here? Since over the last few weeks it was constantly in a bad shape we try to run them in all potentially impactful PRs explicitly

Yeah, seems a good idea ([libraries-]stress would be the pipelines I suppose).

positive diffs

I have a questionable habit of characterizing diffs by their "niceness" 😄.

@EgorBo
Copy link
Member

EgorBo commented Oct 7, 2022

/azp run runtime-coreclr jitstress, runtime-coreclr libraries-jitstress

@azure-pipelines
Copy link

Azure Pipelines successfully started running 2 pipeline(s).

@SingleAccretion
Copy link
Contributor Author

SingleAccretion commented Oct 8, 2022

I looked at the stress failures, all looked pre-existing, except one on ARM:


Assert failure(PID 61 [0x0000003d], Thread: 119 [0x0077]): Assertion failed 'cls != nullptr && !isInvalidHandle(cls)' in 'Analysis:<MakeAndAssignEnvironments>b__12_0(Scope):this' during 'Morph - Inlining' (IL size 241; hash 0x4aab3218; FullOpts)

    File: /__w/1/s/src/coreclr/jit/_typeinfo.h Line: 235
    Image: /root/helix/work/correlation/dotnet

I looked at the dump, and what we have there is a function being inlined, of which the first parameter is a reference type, but when looking at the signature, we get, rather mysteriously, CORINFO_TYPE_VALUECLASS. The method table of this type (as returned by getArgType) looked uninitialized (assuming I got the right stack location for it, I suppose):

0:025> ?? (MethodTable*)0xd0071090
MethodTable * 0xd0071090
   +0x000 m_dwFlags        : 0xf4884050
   +0x004 m_BaseSize       : 0xd0071c90
   +0x008 m_wFlags2        : 0x113c
   +0x00a m_wToken         : 0xd007
   +0x00c m_wNumVirtuals   : 0xdb5c
   +0x00e m_wNumInterfaces : 0xe1d6
   +0x010 debug_m_szClassName : (null) 
   +0x014 m_pParentMethodTable : (null) 
   +0x018 m_pLoaderModule  : 0xffffffff Module
   +0x01c m_pWriteableData : 0x12340000 MethodTableWriteableData
   +0x020 m_pEEClass       : (null) 
   +0x020 m_pCanonMT       : 0
   +0x024 m_pPerInstInfo   : (null) 
   +0x024 m_ElementTypeHnd : 0
   +0x024 m_pMultipurposeSlot1 : 0
   +0x028 m_pInterfaceMap  : 0xdfc265b0 InterfaceInfo_t
   +0x028 m_pMultipurposeSlot2 : 0xdfc265b0

Will assume not related as there are no SIMD types on ARM.

Will also hold off on resolving the conflicts until the CI is up.

We should really delete the SIMD "InitObj" IR form,
but that change had some unfortunate regressions to
it, so, for now, just make it work reliably.
@SingleAccretion
Copy link
Contributor Author

Looks like there are a couple SPMI failures that will need to be investigated.

Consider a promoted two-field HFA stack argument on ARM64.

This argument needs to be processed by multi-reg morphing,
so that it is transformed into a FIELD_LIST, otherwise it
would end up independently promoted yet appear in the IR
as a LCL_VAR.

That was not happening because the number of stack slots
consumed by such an argument is 1 (8 bytes), and the number
of registers is zero (naturally).

As the fix, use the more obviously correct check based
on "structBaseType" to detect when we need to invoke
multi-reg morphing.

No diffs.
@SingleAccretion
Copy link
Contributor Author

Looks like there are a couple SPMI failures that will need to be investigated.

The issues have been solved and this is once again ready for review.

#if !defined(TARGET_X86)
else
{
hasMultiregStructArgs = true;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is this needed here now?

Copy link
Contributor Author

@SingleAccretion SingleAccretion Oct 31, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It used to be set below:

#if FEATURE_MULTIREG_ARGS
        if (isStructArg)
        {
            if (((arg.AbiInfo.NumRegs + arg.AbiInfo.GetStackSlotsNumber()) > 1) ||
                (isHfaArg && argx->TypeGet() == TYP_STRUCT))
            {
                hasMultiregStructArgs = true;
            }
        }

So this is just moving it to here. The benefit of this location is that we don't need to invoke multi-reg morphing if we have already transformed everything into FIELD_LISTs.

call->gtArgs.SetTemp(&arg, tmp);
lvaSetVarAddrExposed(tmp DEBUGARG(AddressExposedReason::TOO_CONSERVATIVE));
hasMultiregStructArgs |= ((arg.AbiInfo.ArgType == TYP_STRUCT) && !arg.AbiInfo.PassedByRef);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I assume this was a preexisting issue on platforms with by-value struct args?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member

@jakobbotsch jakobbotsch left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, nice clean up too.

@jakobbotsch jakobbotsch merged commit 35cb312 into dotnet:main Oct 31, 2022
@SingleAccretion SingleAccretion deleted the LclMorph-SimdLclVar-Upstream branch October 31, 2022 15:11
@ghost ghost locked as resolved and limited conversation to collaborators Nov 30, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI community-contribution Indicates that the PR has been added by a community member
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants