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

[RyuJit/ARMARCH] lower arg with list of float fields. #14753

Merged
merged 5 commits into from
Nov 1, 2017

Conversation

sandreenko
Copy link

@sandreenko sandreenko commented Oct 30, 2017

Support transformation of Hfa that is represented as field list of floats to field list of integers.

It is a temporary solution before we get rid of gtRegNum assignments in the lowering.

Sergey Andreenko added 2 commits October 30, 2017 10:46
Signed-off-by: Sergey Andreenko <seandree@microsoft.com>
Copy was raplced with bitcast many commits ago.
@sandreenko
Copy link
Author

Fix #14549 and #14377

@sandreenko sandreenko changed the title [RyuJit/ARMARCH] lower arg with list of float fields. [WIP][RyuJit/ARMARCH] lower arg with list of float fields. Oct 31, 2017
@sandreenko sandreenko changed the title [WIP][RyuJit/ARMARCH] lower arg with list of float fields. [RyuJit/ARMARCH] lower arg with list of float fields. Oct 31, 2017
@sandreenko
Copy link
Author

@dotnet-bot
test Windows_NT x64_arm64_altjit Checked Build and Test
test Windows_NT x86_arm_altjit Checked Build and Test
test Windows_NT x86_arm_altjit Checked jitstress1
test Windows_NT x86_arm_altjit Checked tailcallstress
test Windows_NT x64_arm64_altjit Checked jitstress1
test Windows_NT x64_arm64_altjit Checked tailcallstress

@sandreenko
Copy link
Author

Ok, Windows_NT x86_arm_altjit Checked tailcallstress shows that SIMD tests passed (Test Result (38 failures / -11)),
A regression in Windows_NT x64_arm64_altjit Checked jitstress1 is unrelated (unstable test).

@sandreenko
Copy link
Author

@dotnet/arm32-contrib PTAL.

assert(argNum == 0);

unsigned fieldNum = 0;
for (GenTreeFieldList *list = arg->AsFieldList(); list != nullptr; list = list->Rest(), fieldNum++)

Choose a reason for hiding this comment

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

I don't think this is correct for non-HFA struct types. I think that the caller of this method should always iterate through a FIELD_LIST, and then call LowerFloatArg on its list items that require it. I think that will also be cleaner.

Copy link
Author

Choose a reason for hiding this comment

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

I do not understand,

the caller of this method should always iterate through a FIELD_LIST

we do not always have a FIELD_LIST . Do you want to move this if-condition to the LowerArg? Could you please give an example when this code is incorrect?

Choose a reason for hiding this comment

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

What I meant was that if the arg is a FIELD_LIST, then you need to iterate through all of its members. Some may be floating point, and some may not.

Copy link
Author

Choose a reason for hiding this comment

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

Got it, thank you. If it is possible than we have a FIELD_LIST with different types in it, which type is set on the FIELD_LIST? And how is register information encoded in info->regnum?

Choose a reason for hiding this comment

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

Each FIELD_LIST should only have the type of the field. The presence of a FIELD_LIST node is an indication that the argument is an aggregate (either a struct or a decomposed long). When it is passed in register(s) the PUTARG node will be a multireg node that has the register list.

Copy link
Author

@sandreenko sandreenko Oct 31, 2017

Choose a reason for hiding this comment

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

struct fgArgTabEntry:: regNumber regNum; // The (first) register to use when passing this argument, set to REG_STK for arguments passed on the stack.

Because regnum is just an int, we can't encode that the first field list member is passed through int register, the second float is passed through float register etc. There is no enough information to construct PUTARG.

Choose a reason for hiding this comment

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

Hmm - then perhaps I misremember. It must be the case that on arm only HFAs are passed in registers (not other struct types). I still think that it would be better and cleaner to iterate through the FIELD_LIST in the caller to this method, and not have it call itself on the child of the FIELD_LIST node.

Copy link
Member

Choose a reason for hiding this comment

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

On ARM, only HFA are passed in floating-point registers. All structs can be passed, or partially passed, in integer registers.

Choose a reason for hiding this comment

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

All structs can be passed, or partially passed, in integer registers.

So does that mean that if we have a TYP_DOUBLE field, if that struct is promoted, we could expect to encounter the TYP_DOUBLE in a FIELD_LIST under a PUTARG_REG or PUTARG_SPLIT?

// return arg if there was in place transformation;
// return a new tree if the root was changed.
//
GenTreePtr Lowering::LowerFloatArg(GenTreePtr arg, fgArgTabEntryPtr info, unsigned argNum)

Choose a reason for hiding this comment

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

I believe it is the case that we are moving away from GenTreePtr to GenTree*.

Copy link
Author

Choose a reason for hiding this comment

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

I have not heard about it, do we?

Choose a reason for hiding this comment

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

This has come up a few times. Here's a relatively recent reference: #14020 (comment)

We should probably put it in the coding conventions. @BruceForstall what do you think?

Copy link
Member

Choose a reason for hiding this comment

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

I agree that it's weird that GenTreePtr is an oddball. Maybe if we want to stop using it, we should agree and then do a copy/replace everywhere. Generally, though, I'm ambivalent about it.

Copy link
Author

Choose a reason for hiding this comment

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

Will change it before the merge, do not want to rerun tests now.

GenTreePtr intNode = LowerFloatArg(node, info, fieldNum);
if (intNode != nullptr)
{
ReplaceArgWithPutArgOrBitcast(list->pCurrent(), intNode);

Choose a reason for hiding this comment

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

A FIELD_LIST doesn't always pass its fields in registers. This should check, because we shouldn't generate a BITCAST for a stack-passed field.

Copy link
Author

Choose a reason for hiding this comment

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

Yes, you are right, this check is right below, line 1416. If it is stack location, then the function returns nullptr.

@sandreenko
Copy link
Author

@dotnet-bot
test Windows_NT x64_arm64_altjit Checked Build and Test
test Windows_NT x86_arm_altjit Checked Build and Test
test Windows_NT x86_arm_altjit Checked jitstress1
test Windows_NT x86_arm_altjit Checked tailcallstress
test Windows_NT x64_arm64_altjit Checked jitstress1
test Windows_NT x64_arm64_altjit Checked tailcallstress

@sandreenko
Copy link
Author

sandreenko commented Nov 1, 2017

PR was updated, I have tried to make the new functions clearer.

@sandreenko
Copy link
Author

@dotnet-bot
test Ubuntu x64 Innerloop Formatting
test Windows_NT x64 Innerloop Formatting

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!

@sandreenko sandreenko merged commit da2f7df into dotnet:master Nov 1, 2017
@sandreenko sandreenko deleted the bitcastForFields branch November 1, 2017 19:06
@sandreenko
Copy link
Author

Merged, thanks for the review.

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

Successfully merging this pull request may close these issues.

4 participants