JIT: use synthesis to repair some reconstruction issues

[AndyAyersMS]

In particular, run synthesis in repair mode for cases where there are profile counts within the method but zero counts in fgFirstBB.

Recall that sparse profiling effectively probes return blocks to determine the method entry count.

So the zero-entry but not zero-everywhere case can happen if we have a method with a very long running loop plus sparse profiling plus OSR -- we will only get profile counts from the instrumented Tier0 method, and it will never return (instead it will always escape to an OSR version which will eventually return, but that version won't be instrumented).

I originally was a bit more ambitious and ran repair for a broader set of reconstruction issues, but lead to a large number of diffs, in part because repair doesn't cope well with irreducible loops.

Leaving the entry count zero can have fairly disastrous impact on the quality of optimizations done in the method.

Addresses quite a few of the worst-performing benchmarks in #84264.

[ghost]

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch, @kunalspathak
See info in area-owners.md if you want to be subscribed.

Issue Details

---

In particular, run synthesis in repair mode for cases where there are profile counts within the method but zero counts in fgFirstBB.

Recall that sparse profiling effectively probes return blocks to determine the method entry count.

So the zero-entry but not zero-everywhere case can happen if we have a method with a very long running loop plus sparse profiling plus OSR -- we will only get profile counts from the instrumented Tier0 method, and it will never return (instead it will always escape to an OSR version which will eventually return, but that version won't be instrumented).

I originally was a bit more ambitious and ran repair for a broader set of reconstruction issues, but lead to a large number of diffs, in part because repair doesn't cope well with irreducible loops.

Leaving the entry count zero can have fairly disastrous impact on the quality of optimizations done in the method.

Addresses quite a few of the worst-performing benchmarks in #84264.

Author:	AndyAyersMS
Assignees:	AndyAyersMS
Labels:	area-CodeGen-coreclr
Milestone:	-

[AndyAyersMS]

Handful of diffs expected. If we had a PGO benchmarks collection we'd see quite a few more.

@EgorBo PTAL
cc @dotnet/jit-contrib

[EgorBo]

Two questions:

1. Is it possible today to detect stale static PGO data and should we still use it or discard completely?
2. Should we enable Dynamic PGO for coreclr_tests.run collection?

[AndyAyersMS]

Two questions:

1. Is it possible today to detect stale static PGO data and should we still use it or discard completely?

If the flowgraph for the method is quite different (that is, if we fail to find an edge in the flowgraph based on IL offsets from schema entries) we will hit the Mismatch cases and throw out all the data. We only expect this to happen with static PGO data but currently we don't assert that this must be so.

This can mean that some trivial/harmless edits to methods will lead to us tossing usable data. It is possible (though not easy) to build approximate matching algorithms that try and recognize when the graphs have the same shape but not the same identifying marks and use that to propagate the stale data. And I suppose do something simialr for class profiles if their IL offsets shift a bit. But not sure it's worth the trouble.

2. Should we enable Dynamic PGO for coreclr_tests.run collection?

Yes, we need to enable more PGO driven collections. Benchmarks would be good to have too.

[AndyAyersMS]

In particular, run synthesis in repair mode for cases where there are profile counts within the method but zero counts in fgFirstBB.

Recall that sparse profiling effectively probes return blocks to determine the method entry count.

So the zero-entry but not zero-everywhere case can happen if we have a method with a very long running loop plus sparse profiling plus OSR -- we will only get profile counts from the instrumented Tier0 method, and it will never return (instead it will always escape to an OSR version which will eventually return, but that version won't be instrumented).

I originally was a bit more ambitious and ran repair for a broader set of reconstruction issues, but lead to a large number of diffs, in part because repair doesn't cope well with irreducible loops.

Leaving the entry count zero can have fairly disastrous impact on the quality of optimizations done in the method.

Addresses quite a few of the worst-performing benchmarks in #84264.

[ghost]

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch, @kunalspathak
See info in area-owners.md if you want to be subscribed.

Issue Details

---

In particular, run synthesis in repair mode for cases where there are profile counts within the method but zero counts in fgFirstBB.

Recall that sparse profiling effectively probes return blocks to determine the method entry count.

So the zero-entry but not zero-everywhere case can happen if we have a method with a very long running loop plus sparse profiling plus OSR -- we will only get profile counts from the instrumented Tier0 method, and it will never return (instead it will always escape to an OSR version which will eventually return, but that version won't be instrumented).

I originally was a bit more ambitious and ran repair for a broader set of reconstruction issues, but lead to a large number of diffs, in part because repair doesn't cope well with irreducible loops.

Leaving the entry count zero can have fairly disastrous impact on the quality of optimizations done in the method.

Addresses quite a few of the worst-performing benchmarks in #84264.

Author:	AndyAyersMS
Assignees:	AndyAyersMS
Labels:	area-CodeGen-coreclr
Milestone:	-

[AndyAyersMS]

Handful of diffs expected. If we had a PGO benchmarks collection we'd see quite a few more.

@EgorBo PTAL
cc @dotnet/jit-contrib

[EgorBo]

Two questions:

1. Is it possible today to detect stale static PGO data and should we still use it or discard completely?
2. Should we enable Dynamic PGO for coreclr_tests.run collection?

[AndyAyersMS]

Two questions:

1. Is it possible today to detect stale static PGO data and should we still use it or discard completely?

If the flowgraph for the method is quite different (that is, if we fail to find an edge in the flowgraph based on IL offsets from schema entries) we will hit the Mismatch cases and throw out all the data. We only expect this to happen with static PGO data but currently we don't assert that this must be so.

This can mean that some trivial/harmless edits to methods will lead to us tossing usable data. It is possible (though not easy) to build approximate matching algorithms that try and recognize when the graphs have the same shape but not the same identifying marks and use that to propagate the stale data. And I suppose do something simialr for class profiles if their IL offsets shift a bit. But not sure it's worth the trouble.

2. Should we enable Dynamic PGO for coreclr_tests.run collection?

Yes, we need to enable more PGO driven collections. Benchmarks would be good to have too.

[AndyAyersMS]

In particular, run synthesis in repair mode for cases where there are profile counts within the method but zero counts in fgFirstBB.

Recall that sparse profiling effectively probes return blocks to determine the method entry count.

So the zero-entry but not zero-everywhere case can happen if we have a method with a very long running loop plus sparse profiling plus OSR -- we will only get profile counts from the instrumented Tier0 method, and it will never return (instead it will always escape to an OSR version which will eventually return, but that version won't be instrumented).

I originally was a bit more ambitious and ran repair for a broader set of reconstruction issues, but lead to a large number of diffs, in part because repair doesn't cope well with irreducible loops.

Leaving the entry count zero can have fairly disastrous impact on the quality of optimizations done in the method.

Addresses quite a few of the worst-performing benchmarks in #84264.

[ghost]

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch, @kunalspathak
See info in area-owners.md if you want to be subscribed.

Issue Details

---

In particular, run synthesis in repair mode for cases where there are profile counts within the method but zero counts in fgFirstBB.

Recall that sparse profiling effectively probes return blocks to determine the method entry count.

So the zero-entry but not zero-everywhere case can happen if we have a method with a very long running loop plus sparse profiling plus OSR -- we will only get profile counts from the instrumented Tier0 method, and it will never return (instead it will always escape to an OSR version which will eventually return, but that version won't be instrumented).

I originally was a bit more ambitious and ran repair for a broader set of reconstruction issues, but lead to a large number of diffs, in part because repair doesn't cope well with irreducible loops.

Leaving the entry count zero can have fairly disastrous impact on the quality of optimizations done in the method.

Addresses quite a few of the worst-performing benchmarks in #84264.

Author:	AndyAyersMS
Assignees:	AndyAyersMS
Labels:	area-CodeGen-coreclr
Milestone:	-

[AndyAyersMS]

Handful of diffs expected. If we had a PGO benchmarks collection we'd see quite a few more.

@EgorBo PTAL
cc @dotnet/jit-contrib

[EgorBo]

Two questions:

1. Is it possible today to detect stale static PGO data and should we still use it or discard completely?
2. Should we enable Dynamic PGO for coreclr_tests.run collection?

[AndyAyersMS]

Two questions:

1. Is it possible today to detect stale static PGO data and should we still use it or discard completely?

If the flowgraph for the method is quite different (that is, if we fail to find an edge in the flowgraph based on IL offsets from schema entries) we will hit the Mismatch cases and throw out all the data. We only expect this to happen with static PGO data but currently we don't assert that this must be so.

This can mean that some trivial/harmless edits to methods will lead to us tossing usable data. It is possible (though not easy) to build approximate matching algorithms that try and recognize when the graphs have the same shape but not the same identifying marks and use that to propagate the stale data. And I suppose do something simialr for class profiles if their IL offsets shift a bit. But not sure it's worth the trouble.

2. Should we enable Dynamic PGO for coreclr_tests.run collection?

Yes, we need to enable more PGO driven collections. Benchmarks would be good to have too.

[AndyAyersMS]

In particular, run synthesis in repair mode for cases where there are profile counts within the method but zero counts in fgFirstBB.

Recall that sparse profiling effectively probes return blocks to determine the method entry count.

So the zero-entry but not zero-everywhere case can happen if we have a method with a very long running loop plus sparse profiling plus OSR -- we will only get profile counts from the instrumented Tier0 method, and it will never return (instead it will always escape to an OSR version which will eventually return, but that version won't be instrumented).

I originally was a bit more ambitious and ran repair for a broader set of reconstruction issues, but lead to a large number of diffs, in part because repair doesn't cope well with irreducible loops.

Leaving the entry count zero can have fairly disastrous impact on the quality of optimizations done in the method.

Addresses quite a few of the worst-performing benchmarks in #84264.

[ghost]

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch, @kunalspathak
See info in area-owners.md if you want to be subscribed.

Issue Details

---

In particular, run synthesis in repair mode for cases where there are profile counts within the method but zero counts in fgFirstBB.

Recall that sparse profiling effectively probes return blocks to determine the method entry count.

So the zero-entry but not zero-everywhere case can happen if we have a method with a very long running loop plus sparse profiling plus OSR -- we will only get profile counts from the instrumented Tier0 method, and it will never return (instead it will always escape to an OSR version which will eventually return, but that version won't be instrumented).

I originally was a bit more ambitious and ran repair for a broader set of reconstruction issues, but lead to a large number of diffs, in part because repair doesn't cope well with irreducible loops.

Leaving the entry count zero can have fairly disastrous impact on the quality of optimizations done in the method.

Addresses quite a few of the worst-performing benchmarks in #84264.

Author:	AndyAyersMS
Assignees:	AndyAyersMS
Labels:	area-CodeGen-coreclr
Milestone:	-

[AndyAyersMS]

Handful of diffs expected. If we had a PGO benchmarks collection we'd see quite a few more.

@EgorBo PTAL
cc @dotnet/jit-contrib

[EgorBo]

Two questions:

1. Is it possible today to detect stale static PGO data and should we still use it or discard completely?
2. Should we enable Dynamic PGO for coreclr_tests.run collection?

[AndyAyersMS]

Two questions:

1. Is it possible today to detect stale static PGO data and should we still use it or discard completely?

If the flowgraph for the method is quite different (that is, if we fail to find an edge in the flowgraph based on IL offsets from schema entries) we will hit the Mismatch cases and throw out all the data. We only expect this to happen with static PGO data but currently we don't assert that this must be so.

This can mean that some trivial/harmless edits to methods will lead to us tossing usable data. It is possible (though not easy) to build approximate matching algorithms that try and recognize when the graphs have the same shape but not the same identifying marks and use that to propagate the stale data. And I suppose do something simialr for class profiles if their IL offsets shift a bit. But not sure it's worth the trouble.

2. Should we enable Dynamic PGO for coreclr_tests.run collection?

Yes, we need to enable more PGO driven collections. Benchmarks would be good to have too.

[AndyAyersMS]

In particular, run synthesis in repair mode for cases where there are profile counts within the method but zero counts in fgFirstBB.

Recall that sparse profiling effectively probes return blocks to determine the method entry count.

So the zero-entry but not zero-everywhere case can happen if we have a method with a very long running loop plus sparse profiling plus OSR -- we will only get profile counts from the instrumented Tier0 method, and it will never return (instead it will always escape to an OSR version which will eventually return, but that version won't be instrumented).

I originally was a bit more ambitious and ran repair for a broader set of reconstruction issues, but lead to a large number of diffs, in part because repair doesn't cope well with irreducible loops.

Leaving the entry count zero can have fairly disastrous impact on the quality of optimizations done in the method.

Addresses quite a few of the worst-performing benchmarks in #84264.

[ghost]

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch, @kunalspathak
See info in area-owners.md if you want to be subscribed.

Issue Details

---

In particular, run synthesis in repair mode for cases where there are profile counts within the method but zero counts in fgFirstBB.

Recall that sparse profiling effectively probes return blocks to determine the method entry count.

So the zero-entry but not zero-everywhere case can happen if we have a method with a very long running loop plus sparse profiling plus OSR -- we will only get profile counts from the instrumented Tier0 method, and it will never return (instead it will always escape to an OSR version which will eventually return, but that version won't be instrumented).

I originally was a bit more ambitious and ran repair for a broader set of reconstruction issues, but lead to a large number of diffs, in part because repair doesn't cope well with irreducible loops.

Leaving the entry count zero can have fairly disastrous impact on the quality of optimizations done in the method.

Addresses quite a few of the worst-performing benchmarks in #84264.

Author:	AndyAyersMS
Assignees:	AndyAyersMS
Labels:	area-CodeGen-coreclr
Milestone:	-

[AndyAyersMS]

Handful of diffs expected. If we had a PGO benchmarks collection we'd see quite a few more.

@EgorBo PTAL
cc @dotnet/jit-contrib

[EgorBo]

Two questions:

1. Is it possible today to detect stale static PGO data and should we still use it or discard completely?
2. Should we enable Dynamic PGO for coreclr_tests.run collection?

[AndyAyersMS]

Two questions:

1. Is it possible today to detect stale static PGO data and should we still use it or discard completely?

If the flowgraph for the method is quite different (that is, if we fail to find an edge in the flowgraph based on IL offsets from schema entries) we will hit the Mismatch cases and throw out all the data. We only expect this to happen with static PGO data but currently we don't assert that this must be so.

This can mean that some trivial/harmless edits to methods will lead to us tossing usable data. It is possible (though not easy) to build approximate matching algorithms that try and recognize when the graphs have the same shape but not the same identifying marks and use that to propagate the stale data. And I suppose do something simialr for class profiles if their IL offsets shift a bit. But not sure it's worth the trouble.

2. Should we enable Dynamic PGO for coreclr_tests.run collection?

Yes, we need to enable more PGO driven collections. Benchmarks would be good to have too.

[AndyAyersMS]

In particular, run synthesis in repair mode for cases where there are profile counts within the method but zero counts in fgFirstBB.

Recall that sparse profiling effectively probes return blocks to determine the method entry count.

So the zero-entry but not zero-everywhere case can happen if we have a method with a very long running loop plus sparse profiling plus OSR -- we will only get profile counts from the instrumented Tier0 method, and it will never return (instead it will always escape to an OSR version which will eventually return, but that version won't be instrumented).

I originally was a bit more ambitious and ran repair for a broader set of reconstruction issues, but lead to a large number of diffs, in part because repair doesn't cope well with irreducible loops.

Leaving the entry count zero can have fairly disastrous impact on the quality of optimizations done in the method.

Addresses quite a few of the worst-performing benchmarks in #84264.

[ghost]

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch, @kunalspathak
See info in area-owners.md if you want to be subscribed.

Issue Details

---

In particular, run synthesis in repair mode for cases where there are profile counts within the method but zero counts in fgFirstBB.

Recall that sparse profiling effectively probes return blocks to determine the method entry count.

So the zero-entry but not zero-everywhere case can happen if we have a method with a very long running loop plus sparse profiling plus OSR -- we will only get profile counts from the instrumented Tier0 method, and it will never return (instead it will always escape to an OSR version which will eventually return, but that version won't be instrumented).

I originally was a bit more ambitious and ran repair for a broader set of reconstruction issues, but lead to a large number of diffs, in part because repair doesn't cope well with irreducible loops.

Leaving the entry count zero can have fairly disastrous impact on the quality of optimizations done in the method.

Addresses quite a few of the worst-performing benchmarks in #84264.

Author:	AndyAyersMS
Assignees:	AndyAyersMS
Labels:	area-CodeGen-coreclr
Milestone:	-

[AndyAyersMS]

Handful of diffs expected. If we had a PGO benchmarks collection we'd see quite a few more.

@EgorBo PTAL
cc @dotnet/jit-contrib

[EgorBo]

Two questions:

1. Is it possible today to detect stale static PGO data and should we still use it or discard completely?
2. Should we enable Dynamic PGO for coreclr_tests.run collection?

[AndyAyersMS]

Two questions:

1. Is it possible today to detect stale static PGO data and should we still use it or discard completely?

If the flowgraph for the method is quite different (that is, if we fail to find an edge in the flowgraph based on IL offsets from schema entries) we will hit the Mismatch cases and throw out all the data. We only expect this to happen with static PGO data but currently we don't assert that this must be so.

This can mean that some trivial/harmless edits to methods will lead to us tossing usable data. It is possible (though not easy) to build approximate matching algorithms that try and recognize when the graphs have the same shape but not the same identifying marks and use that to propagate the stale data. And I suppose do something simialr for class profiles if their IL offsets shift a bit. But not sure it's worth the trouble.

2. Should we enable Dynamic PGO for coreclr_tests.run collection?

Yes, we need to enable more PGO driven collections. Benchmarks would be good to have too.

[AndyAyersMS]

In particular, run synthesis in repair mode for cases where there are profile counts within the method but zero counts in fgFirstBB.

Recall that sparse profiling effectively probes return blocks to determine the method entry count.

So the zero-entry but not zero-everywhere case can happen if we have a method with a very long running loop plus sparse profiling plus OSR -- we will only get profile counts from the instrumented Tier0 method, and it will never return (instead it will always escape to an OSR version which will eventually return, but that version won't be instrumented).

I originally was a bit more ambitious and ran repair for a broader set of reconstruction issues, but lead to a large number of diffs, in part because repair doesn't cope well with irreducible loops.

Leaving the entry count zero can have fairly disastrous impact on the quality of optimizations done in the method.

Addresses quite a few of the worst-performing benchmarks in #84264.

[ghost]

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch, @kunalspathak
See info in area-owners.md if you want to be subscribed.

Issue Details

---

In particular, run synthesis in repair mode for cases where there are profile counts within the method but zero counts in fgFirstBB.

Recall that sparse profiling effectively probes return blocks to determine the method entry count.

So the zero-entry but not zero-everywhere case can happen if we have a method with a very long running loop plus sparse profiling plus OSR -- we will only get profile counts from the instrumented Tier0 method, and it will never return (instead it will always escape to an OSR version which will eventually return, but that version won't be instrumented).

I originally was a bit more ambitious and ran repair for a broader set of reconstruction issues, but lead to a large number of diffs, in part because repair doesn't cope well with irreducible loops.

Leaving the entry count zero can have fairly disastrous impact on the quality of optimizations done in the method.

Addresses quite a few of the worst-performing benchmarks in #84264.

Author:	AndyAyersMS
Assignees:	AndyAyersMS
Labels:	area-CodeGen-coreclr
Milestone:	-

[AndyAyersMS]

Handful of diffs expected. If we had a PGO benchmarks collection we'd see quite a few more.

@EgorBo PTAL
cc @dotnet/jit-contrib

[EgorBo]

Two questions:

1. Is it possible today to detect stale static PGO data and should we still use it or discard completely?
2. Should we enable Dynamic PGO for coreclr_tests.run collection?

[AndyAyersMS]

Two questions:

1. Is it possible today to detect stale static PGO data and should we still use it or discard completely?

If the flowgraph for the method is quite different (that is, if we fail to find an edge in the flowgraph based on IL offsets from schema entries) we will hit the Mismatch cases and throw out all the data. We only expect this to happen with static PGO data but currently we don't assert that this must be so.

This can mean that some trivial/harmless edits to methods will lead to us tossing usable data. It is possible (though not easy) to build approximate matching algorithms that try and recognize when the graphs have the same shape but not the same identifying marks and use that to propagate the stale data. And I suppose do something simialr for class profiles if their IL offsets shift a bit. But not sure it's worth the trouble.

2. Should we enable Dynamic PGO for coreclr_tests.run collection?

Yes, we need to enable more PGO driven collections. Benchmarks would be good to have too.

[AndyAyersMS]

In particular, run synthesis in repair mode for cases where there are profile counts within the method but zero counts in fgFirstBB.

Recall that sparse profiling effectively probes return blocks to determine the method entry count.

So the zero-entry but not zero-everywhere case can happen if we have a method with a very long running loop plus sparse profiling plus OSR -- we will only get profile counts from the instrumented Tier0 method, and it will never return (instead it will always escape to an OSR version which will eventually return, but that version won't be instrumented).

I originally was a bit more ambitious and ran repair for a broader set of reconstruction issues, but lead to a large number of diffs, in part because repair doesn't cope well with irreducible loops.

Leaving the entry count zero can have fairly disastrous impact on the quality of optimizations done in the method.

Addresses quite a few of the worst-performing benchmarks in #84264.

[ghost]

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch, @kunalspathak
See info in area-owners.md if you want to be subscribed.

Issue Details

---

In particular, run synthesis in repair mode for cases where there are profile counts within the method but zero counts in fgFirstBB.

Recall that sparse profiling effectively probes return blocks to determine the method entry count.

So the zero-entry but not zero-everywhere case can happen if we have a method with a very long running loop plus sparse profiling plus OSR -- we will only get profile counts from the instrumented Tier0 method, and it will never return (instead it will always escape to an OSR version which will eventually return, but that version won't be instrumented).

I originally was a bit more ambitious and ran repair for a broader set of reconstruction issues, but lead to a large number of diffs, in part because repair doesn't cope well with irreducible loops.

Leaving the entry count zero can have fairly disastrous impact on the quality of optimizations done in the method.

Addresses quite a few of the worst-performing benchmarks in #84264.

Author:	AndyAyersMS
Assignees:	AndyAyersMS
Labels:	area-CodeGen-coreclr
Milestone:	-

[AndyAyersMS]

Handful of diffs expected. If we had a PGO benchmarks collection we'd see quite a few more.

@EgorBo PTAL
cc @dotnet/jit-contrib

[EgorBo]

Two questions:

1. Is it possible today to detect stale static PGO data and should we still use it or discard completely?
2. Should we enable Dynamic PGO for coreclr_tests.run collection?

[AndyAyersMS]

Two questions:

1. Is it possible today to detect stale static PGO data and should we still use it or discard completely?

If the flowgraph for the method is quite different (that is, if we fail to find an edge in the flowgraph based on IL offsets from schema entries) we will hit the Mismatch cases and throw out all the data. We only expect this to happen with static PGO data but currently we don't assert that this must be so.

This can mean that some trivial/harmless edits to methods will lead to us tossing usable data. It is possible (though not easy) to build approximate matching algorithms that try and recognize when the graphs have the same shape but not the same identifying marks and use that to propagate the stale data. And I suppose do something simialr for class profiles if their IL offsets shift a bit. But not sure it's worth the trouble.

2. Should we enable Dynamic PGO for coreclr_tests.run collection?

Yes, we need to enable more PGO driven collections. Benchmarks would be good to have too.