Restore GT_INDEX_ADDR after #13682.#13701
Conversation
This restores the `GT_INDEX_ADDR` changes.
`genConsumeReg` marks the consumed register as not a GC pointer, as it assumes that the input register dies at the first instruction generated by the node. This is not the case for `INDEX_ADDR`, however, as the base register is multiply-used. As such, we need to mark the base regsiter as containing a GC pointer until we are finished generating the code for this node. Fixes
This function does not need to update the array info map when cloning a `GT_IND` if the address is a `GT_INDEX_ADDR`.
We were attempting to generate `base + index * size` using `MADD`, but had the registers in the wrong order and were generating `base * index + size`. This change fixes the register order s.t. the expected instruction is generated. Fixes #13593.
|
@briansull @BruceForstall @CarolEidt @jkotas @dotnet/jit-contrib PTAL |
|
@dotnet-bot help |
|
Welcome to the dotnet/coreclr Repository The following is a list of valid commands on this PR. To invoke a command, comment the indicated phrase on the PR The following commands are valid for all PRs and repositories. Click to expand
The following jobs are launched by default for each PR against dotnet/coreclr:master. Click to expand
The following optional jobs are available in PRs against dotnet/coreclr:master. Click to expand
Have a nice day! |
|
@dotnet-bot |
|
@dotnet-bot test Windows_NT x64 corefx_minopts |
| GenTree::s_gtNodeSizes[GT_FTN_ADDR] = TREE_NODE_SZ_LARGE; | ||
| GenTree::s_gtNodeSizes[GT_BOX] = TREE_NODE_SZ_LARGE; | ||
| GenTree::s_gtNodeSizes[GT_INDEX] = TREE_NODE_SZ_LARGE; | ||
| GenTree::s_gtNodeSizes[GT_INDEX_ADDR] = TREE_NODE_SZ_LARGE; |
|
@dotnet-bot test OSX10.12 gcstress0x3 |
|
CoreFX minopts failure is a build issue. |
| return compRoot->m_arrayInfoMap; | ||
| } | ||
|
|
||
| inline bool TryGetArrayInfo(GenTreeIndir* indir, ArrayInfo* arrayInfo) |
There was a problem hiding this comment.
This method could use a function header explaining what it handles. (why it returns true vs. false etc...)
| if (tree->gtFlags & GTF_IND_ARR_INDEX) | ||
| { | ||
| ArrayInfo arrInfo; | ||
| if (TryGetArrayInfo(tree->AsIndir(), &arrInfo) && !tree->AsIndir()->gtOp1->OperIs(GT_INDEX_ADDR)) |
There was a problem hiding this comment.
Did you consider passing a argument stating whether we should cons up an ArrayInfo for the GT_INDEX_ADDR case.
Here we cons it up and discard it.
| if (indir->gtOp1->OperIs(GT_INDEX_ADDR)) | ||
| { | ||
| GenTreeIndexAddr* const indexAddr = indir->gtOp1->AsIndexAddr(); | ||
| *arrayInfo = ArrayInfo(indexAddr->gtElemType, indexAddr->gtElemSize, indexAddr->gtElemOffset, |
There was a problem hiding this comment.
Can you add a comment saying why we cons up an ArrayInfo here.
CarolEidt
left a comment
There was a problem hiding this comment.
LGTM (aside from a couple of typos)
| genConsumeReg(index); | ||
|
|
||
| // NOTE: `genConsumeReg` marks the consumed register as not a GC pointer, as it assumes that the input registers | ||
| // die at the first instruction generated by the node. This is not the case for `INDEX_ADDR`, however, as the |
| genConsumeReg(index); | ||
|
|
||
| // NOTE: `genConsumeReg` marks the consumed register as not a GC pointer, as it assumes that the input registers | ||
| // die at the first instruction generated by the node. This is not the case for `INDEX_ADDR`, however, as the |
|
@dotnet-bot test Tizen armel Cross Debug Build |
These changes undo the reversion of the
GT_INDEX_ADDRchanges and fix a few bugs that were identified after the fact. Each bug fix is contained in a separate commit.Supersedes #13639 and #13665.
Fixes https://github.com/dotnet/corefx/issues/23586.