Skip to content
This repository has been archived by the owner on Jan 23, 2023. It is now read-only.

Minor cleanup in BuildHWIntrinsic to better support adding containment to the existing HWIntrinsic nodes. #18078

Merged
merged 1 commit into from
May 23, 2018

Conversation

tannergooding
Copy link
Member

@tannergooding tannergooding commented May 22, 2018

The previous code was making a lot of assumptions about the uselist and the ordering of the LocationInfo in it. I found several of these assumptions to be generally incorrect when working on adding the FMA instruction set.

This updates the BuildHWIntrinsic code to be more robust (both against the current code and against future changes) by ensuring that the LocationInfo we are using maps exactly to the operand we think it should.

The original comment was invalidated by #16517. The new changes does some minor cleanup to better support some upcoming changes to support containment on the existing HWIntrinsic nodes.

@tannergooding
Copy link
Member Author

FYI. @fiigii, @CarolEidt

@tannergooding
Copy link
Member Author

The two biggest issues I saw were:

  1. In some cases there is no location info added to the use list (generally contained nodes, sometimes indir nodes)
  2. In other cases, there is more than one location info, per operand, in the use list (generally GT_LONG nodes on non-64bit machines)

@tannergooding
Copy link
Member Author

@dotnet-bot test Windows_NT x64 Checked jitincompletehwintrinsic
@dotnet-bot test Windows_NT x64 Checked jitx86hwintrinsicnoavx
@dotnet-bot test Windows_NT x64 Checked jitx86hwintrinsicnoavx2
@dotnet-bot test Windows_NT x64 Checked jitx86hwintrinsicnosimd
@dotnet-bot test Windows_NT x64 Checked jitnox86hwintrinsic

@dotnet-bot test Windows_NT x86 Checked jitincompletehwintrinsic
@dotnet-bot test Windows_NT x86 Checked jitx86hwintrinsicnoavx
@dotnet-bot test Windows_NT x86 Checked jitx86hwintrinsicnoavx2
@dotnet-bot test Windows_NT x86 Checked jitx86hwintrinsicnosimd
@dotnet-bot test Windows_NT x86 Checked jitnox86hwintrinsic

@dotnet-bot test Ubuntu x64 Checked jitincompletehwintrinsic
@dotnet-bot test Ubuntu x64 Checked jitx86hwintrinsicnoavx
@dotnet-bot test Ubuntu x64 Checked jitx86hwintrinsicnoavx2
@dotnet-bot test Ubuntu x64 Checked jitx86hwintrinsicnosimd
@dotnet-bot test Ubuntu x64 Checked jitnox86hwintrinsic

}
else
{
assert(numArgs == (op2 == nullptr) ? 1 : 2);
Copy link
Member Author

Choose a reason for hiding this comment

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

This was incorrect for op1 == nullptr

op2 = op1->AsArgList()->Rest()->Current();
op3 = op1->AsArgList()->Rest()->Rest()->Current();
op1 = op1->AsArgList()->Current();
assert(numArgs >= 3);
Copy link
Member Author

Choose a reason for hiding this comment

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

The assert on L2315 partially invalidates this as it requires numArgs == 3

}

if (buildUses)
{
if (numArgs > 3)
Copy link
Member Author

Choose a reason for hiding this comment

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

There are currently 0 cases where we have an intrinsic with more than 3 args that would reach the register allocator.

@tannergooding tannergooding changed the title Updating BuildHWIntrinsic to no longer make so many assumptions. Minor cleanup in BuildHWIntrinsic to better support adding containment to the existing HWIntrinsic nodes. May 23, 2018
@tannergooding
Copy link
Member Author

FYI. @CarolEidt. This has been cleaned up now that #16517 is merged. Could you review when you get the chance?

}

buildUses = false;

Choose a reason for hiding this comment

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

This will cause uses not to be built in the case where op1 is a contained memory op. I'm pretty sure that case needs to be handled, so I suspect that the buildUses = false belongs in the if-clause.

case NI_SSE42_Crc32:
{
// TODO - currently we use the BaseType to bring the type of the second argument
// to the code generator. May encode the overload info in other way.

Choose a reason for hiding this comment

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

Nit: TODO comments should be qualified - here it should probably be TODO-XArch-Cleanup (see https://github.com/dotnet/coreclr/blob/master/Documentation/coding-guidelines/clr-jit-coding-conventions.md#7.1.5). Also, you could expand the last sentence to "We may want to encode the overload info in another way." to be clearer.

Copy link

@CarolEidt CarolEidt left a comment

Choose a reason for hiding this comment

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

LGTM thanks!


if (!compiler->canUseVexEncoding())
{
assert(isRMW);
Copy link
Member Author

Choose a reason for hiding this comment

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

Moved the assert into the if statement, since it is only RMW on non-VEX hardware.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants