-
Notifications
You must be signed in to change notification settings - Fork 2.7k
Work towards objects stack allocation #6653
Conversation
TYP_REF, 0, | ||
gtNewArgList(op1)); | ||
op1 = gtNewAllocObjNode( info.compCompHnd->getNewHelper(&resolvedToken, info.compMethodHnd), | ||
resolvedToken.hClass, TYP_REF, op1 ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This code always assigns the newly allocated object to a temp. However, it's not entirely clear that this is a fundamental requirement. So, either here or above the call to impAssignTempGen
, I would add a comment that the ObjectAllocator
relies on this.
LGTM, other than one suggestion for a comment. |
assert(tree != nullptr); | ||
assert(tree->OperGet() != GT_ALLOCOBJ); | ||
|
||
return Compiler::fgWalkResult::WALK_CONTINUE; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like the indentation is off in this function.
LGTM aside from a few nits. |
@dotnet-bot test OSX x64 Checked Build and Test |
@dotnet-bot test Ubuntu x64 Checked Build and Test |
1 similar comment
@dotnet-bot test Ubuntu x64 Checked Build and Test |
CORINFO_CLASS_HANDLE gtAllocObjClsHnd; | ||
|
||
GenTreeAllocObj(var_types type, unsigned int helper, CORINFO_CLASS_HANDLE clsHnd, GenTreePtr op | ||
DEBUGARG(bool largeNode = false)) : |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we really need another DEBUGARG() here?
PeterK is currently revisiting all uses of "largeNodes" in our codebase.
It would seem that we should know if this node needs to be large or not and not have every callsite determine this properly.
…j-lowering into separate phase 1. Introduced `GT_ALLOCOBJ` node to mark places where object allocation happens 2. In `importer.cpp` changed lowering of allocation part of newobj instruction from an allocation helper call to a `GT_ALLOCOBJ` node creation 3. Created new phase `ObjectAllocator` (`PHASE_ALLOCATE_OBJECTS`) and put it right after dominator computing (we will need the information for escape analysis) 4. Current implementation of ObjectAllocator walks over all basic blocks having flag `BBF_HAS_NEWOBJ` set and replaces `GT_ALLOCOBJ` with an allocation helper call
@dotnet-bot test Windows_NT x86 ryujit Checked Build and Test |
LGTM |
1 similar comment
LGTM |
Work towards objects stack allocation Commit migrated from dotnet/coreclr@3779842
Work towards objects stack allocation: moved allocation part of newobj-lowering into separate phase
GT_ALLOCOBJ
node to mark places where object allocation happensimporter.cpp
changed lowering of allocation part of newobj instruction from an allocation helper call to aGT_ALLOCOBJ
node creationObjectAllocator
(PHASE_ALLOCATE_OBJECTS
) and put it right after dominator computing (we will need the information for escape analysis)BBF_HAS_NEWOBJ
set and replacesGT_ALLOCOBJ
with an allocation helper callI did coreclr testing and throughput measurement. We have one assembly diff (an improvement) related to deleting unreachable basic blocks. Throughput remains the same.
@erozenfeld PTAL
cc @dotnet/jit-contrib