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

Encapsulate live var analysis in its own class.#8856

Merged
pgavlin merged 3 commits intodotnet:masterfrom
pgavlin:LVAThroughput
Jan 9, 2017
Merged

Encapsulate live var analysis in its own class.#8856
pgavlin merged 3 commits intodotnet:masterfrom
pgavlin:LVAThroughput

Conversation

@pgavlin
Copy link

@pgavlin pgavlin commented Jan 9, 2017

This change moves the implementation of live variable analysis from a
single function into a class in which the per-block portion of the
algorithm is contained in its own function. There is no functional
change.

This change moves the implementation of live variable analysis from a
single function into a class in which the per-block portion of the
algorithm is contained in its own function. There is no functional
change.
@pgavlin
Copy link
Author

pgavlin commented Jan 9, 2017

@CarolEidt @dotnet/jit-contrib PTAL

@sivarv
Copy link
Member

sivarv commented Jan 9, 2017

Zero SPMI asm diffs due to this change?

@pgavlin
Copy link
Author

pgavlin commented Jan 9, 2017

@sivarv: correct.

}

noway_assert(opts.compDbgCode && (info.compVarScopesCount > 0));
/* For lvaKeepAliveAndReportThis methods, "m_compiler" has to be kept alive everywhere
Copy link

Choose a reason for hiding this comment

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

Incorrect comment update - "m_compiler" should stay "this".

Copy link
Author

Choose a reason for hiding this comment

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

That's what I get for '<,'>s/this/m_compiler/g... Nice catch.

noway_assert(opts.compDbgCode && (info.compVarScopesCount > 0));
/* For lvaKeepAliveAndReportThis methods, "m_compiler" has to be kept alive everywhere
Note that a function may end in a throw on an infinite loop (as opposed to a return).
"m_compiler" has to be alive everywhere even in such methods. */
Copy link

Choose a reason for hiding this comment

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

m_compiler -> this again

@mikedn
Copy link

mikedn commented Jan 9, 2017

It's great to see a bit of refactoring going in the JIT codebase 😄

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.

I suspect that the C++ compilers can optimize this to be as efficient as before, but given that the lclVar sets are now members of the class instance, it might be good to do a throughput measurement just to be certain.
LGTM modulo a couple of suggestions.

}

for (block = fgLastBB; block; block = block->bbPrev)
void PerBlock(BasicBlock* block, bool updateInternalOnly, bool keepAliveThis)

Choose a reason for hiding this comment

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

I would prefer a more meaningful name for this. PerBlock() could be something that just returns the liveness info for the block, rather than computing it. How about PerBlockAnalysis?

Copy link
Author

Choose a reason for hiding this comment

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

PerBlockAnalysis sounds good to me. Thanks for the suggestion!

else
{
VarSetOps::AddElemD(this, liveOut, lvaTable[info.compThisArg].lvVarIndex);
VarSetOps::Assign(m_compiler, block->bbLiveIn, m_liveIn);

Choose a reason for hiding this comment

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

Can we use swap here?

Copy link
Author

Choose a reason for hiding this comment

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

I don't think so, no.

{
block->bbHeapLiveIn = m_heapLiveIn;
block->bbHeapLiveOut = m_heapLiveOut;
m_changed = true;

Choose a reason for hiding this comment

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

Does bbHeapLive change request PerBlockAnalysis iterations? Can we calculate bbHeapLive(In/Out) separately from live variables?

Copy link
Author

Choose a reason for hiding this comment

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

It shouldn't change after all blocks have been visited, but updating it is essentially free.

@pgavlin
Copy link
Author

pgavlin commented Jan 9, 2017

The arm cross build failure appears to be infrastructural.

@dotnet-bot test Windows_NT arm Cross Release Build

@pgavlin pgavlin merged commit f4d2709 into dotnet:master Jan 9, 2017
@pgavlin pgavlin deleted the LVAThroughput branch January 9, 2017 21:34
@karelz karelz modified the milestone: 2.0.0 Aug 28, 2017
picenka21 pushed a commit to picenka21/runtime that referenced this pull request Feb 18, 2022
Encapsulate live var analysis in its own class.

Commit migrated from dotnet/coreclr@f4d2709
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.

7 participants