Skip to content

Propagate assertions through Exception handlers. - #160

Merged
sandreenko merged 2 commits into
dotnet:masterfrom
sandreenko:optAssertionProp
Nov 21, 2019
Merged

Propagate assertions through Exception handlers.#160
sandreenko merged 2 commits into
dotnet:masterfrom
sandreenko:optAssertionProp

Conversation

@sandreenko

@sandreenkosandreenko commented Nov 20, 2019

Copy link
Copy Markdown
Contributor

for such C# code:

int[] array = new int[100];
int i = 0;
while (i < 100)
{
try
{
}
catch (NullReferenceException arg_16_0)
{
array[i] = i; <- that bounds check can't be eliminated without that change.
}
array[i] = i; <- that bounds check can't be eliminated without that change.
i++;
}

without that change, we were not able to eliminate bounds/null checks in/after exception handler blocks.

The initial restriction was added because we can jump to the exception handler from any instruction in the try region. So we set bbAssertionIn to empty set to guarantee that we don't propagate something that is true only for some points in the try block.

With that change, we calculate assertions that are always valid in the try block as firstTryBlock->bbAssertionIn & lastTryBlock->bbAssertionOut.

We always create unique assertions so if we have smth like:

null check V01 <- <- assertion01 is created
try { <- assertion01 is alive
V01 = smth <- assertion01 is killed
null check V01 <- assertion02 is created
} <- assertion02 is alive
catch <- no asserion is alive, because assertion01 and assertion02 are different assertions.
{}

firstTryBlock->bbAssertionIn & lastTryBlock->bbAssertionOut will still be valid.

diffs:
System.Private.CoreLib: -114 (-0.00% of base)
21 total methods with Code Size differences (21 improved, 0 regressed), 26848 unchanged.

framework assemblies: -1111 (-0.00% of base)
207 total methods with Code Size differences (207 improved, 0 regressed), 185568 unchanged.

The improvements look like expected: we eliminate null checks and bounds checks in and after handlers.

I will improve CSE later in a separate PR because it has other pessimizationz as well.

@sandreenkosandreenko added area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI optimization labels Nov 20, 2019
@sandreenko
sandreenko marked this pull request as ready for review November 21, 2019 00:51
@sandreenko

Copy link
Copy Markdown
ContributorAuthor

PTAL @dotnet/jit-contrib

@CarolEidtCarolEidt left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Nice!

@sandreenko

Copy link
Copy Markdown
ContributorAuthor

/azp list

@sandreenko

Copy link
Copy Markdown
ContributorAuthor

/azp run runtime-coreclr outerloop

@azure-pipelines

Copy link
Copy Markdown
Azure Pipelines could not run because the pipeline triggers exclude this branch/path.

@sandreenko

Copy link
Copy Markdown
ContributorAuthor

Azure Pipelines could not run because the pipeline triggers exclude this branch/path.

Hm, @jashook do you know what I am doing wrong?
but outerloop is red anyway, so I think I will skip it here.

@jashook

Copy link
Copy Markdown
Contributor

@sandreenko this is unfortunately a workflow regression that we are trying to address with Azure Dev Ops. Currently the only way to launch the pipeline is to go to https://dev.azure.com/dnceng/public/_build?definitionId=655 and manually queue.

Note that the queue branch is the same as it was for the jitstress pipelines: refs/pull/pr_number/head

@jashook

Copy link
Copy Markdown
Contributor

/cc @dotnet/jit-contrib @dotnet/runtime-infrastructure

@briansull

Copy link
Copy Markdown
Contributor

Optimization into catrch clauses are unlikely to improve performance measurably as we don't expect catch clauses to be executed on any hot code path. (Additionally the runtime will use thousands of cycles when dispatching into a catch)
However if this also optimizes into an (un-cloned) finally block then that would be a useful optimization to enable.

@erozenfelderozenfeld left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

LGTM

@sandreenko
sandreenko merged commit 028c433 into dotnet:masterNov 21, 2019
@sandreenko
sandreenko deleted the optAssertionProp branch November 21, 2019 21:40
@karelzkarelz added this to the 5.0.0 milestone Aug 18, 2020
@ghostghost locked as resolved and limited conversation to collaborators Dec 11, 2020
Sign up for freeto subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

area-CodeGen-coreclrCLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMIoptimization

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants

@sandreenko@jashook@briansull@CarolEidt@erozenfeld@karelz