| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Allow jit to inline methods with the cpblk IL opcode. Add a test case
where such an inline happens.
|
|
Prevents RandomPolicy from being overly aggressive with small methods
that can lead to excessive inlining.
Closes #4711. Undoes #4704.
|
|
The LotsOfInlines test times out under COMPlus_JitStress=1.
(http://dotnet-ci.cloudapp.net/job/dotnet_coreclr/job/master/job/x64_checked_windows_nt_jitstress1/48/testReport/).
This change disables it from running under JitStress modes that might
affect optimizations required for it to run in reasonable time.
|
|
Use the time budget and time estimates to stop inlining once the
overall jit time increase estimate for the method is 10x the initial
jit time estimate.
This is implemented as part of `LegacyPolicy` and so can impact
the current inline behavior.
The budget is intentionally set quite high so that it only kicks in
for very rare cases where the call tree below the root is deep and wide
with many small methods. In extended testing on desktop this limit
fires in exactly two cases, both HFA tests.
In CoreCLR tests 12 of the HFA tests hit this limit. I've added
a directed test case here that came from the original bug report.
Closes #2472.
|
|
Ensures that execution of these tests always invokes the jit's optimizer,
regardless of the build configuration.
See issue #4124.
|
|
Upgrade dotnet CLI version, accumulated project.json changes
|
|
Restore is performed once as a batch. csproj's share project.jsons, so restoring for each one was a race to update the lockfile.
|
|
Change #3436 added asserts that checked that the LegacyPolicy would not
see multiple failing observations when inlining because we expect the
inliner to fail fast when it hits the first bad observation.
This change adds a test case that shows one example where we could get
two failing observations, along with code changes to fix the issue.
When an inlinee has invalid IL, an exception is raised and caught in
`jitNativeCode`. The catch there sets the inline result to the never
state. A failure code is propagated back to `fgInvokeInlineeCompiler`
which redundantly sets the inline result to a failing state with a
generic "something bad happened" observation. This second observation
triggers an assert since the jit is inlining and the result is already
known to be a failure.
The fix is to check in `fgInvokeInlineeCompiler` if the inline result
is already known to be in a failing state, and if so, forgo the new
observation.
|
|
Ensure the jit can avoid or back out of inlines where types are
mismatched. Remove some assertion checking that was looking at
call actuals versus formals and instead let the newly added inline
bail out handle cases where there are mismatches.
|
|
|
|
Initial version of the inline tree
|
|
Extend `inlExpLst` to to describe the full inlining tree in a method, with a
corresponding dump method.
Add a top-level tree node to serve as the root of the tree. Set this as the
inline context for all top-level expressions. Update the code that links in new
nodes when there is a successful inline to build the tree links. Since the
child list is extended by a prepend and candidates are currently visited in
lexical (increasing "local" IL offset) order, the child list ends up reversed.
The dumper prints the list entries from back to front to compensate so the tree
display reflects lexical order.
Capture IL offset to help in identifying call sites. Note this is incomplete and
offets are often missing copies of the parent's offset. Will work on improving
this subsequently.
Update the depth check to return the depth. This is currently only used in
diagnostic messages.
Remove some unused inlining-related data members from the compiler class. Cache
the `JitPrintInlinedMethods` config value and use it to dump the tree when
inlining is done, if there were any inlines.
The jit traditionally (and probably inadvertently) allowed one level of
recursive inlining. Added a test case showing how this can happen.
Because there is now a top-level inlining context, the recursion check can now
potentially detect and block these recursive inlines. Support legacy behavior
for now by setting `ixlCode` to `nullptr` in the top-level record.
This change should be no diff.
Sample output:
```
Inlines into Enumerable:Where(ref,ref):ref
[IL=3] Error:ArgumentNull(ref):ref
[IL=17] Error:ArgumentNull(ref):ref
[IL=?] WhereArrayIterator`1:.ctor(ref,ref):this
[IL=?] Iterator`1:.ctor():this
[IL=?] Object:.ctor():this
[IL=?] Environment:get_CurrentManagedThreadId():int
[IL=?] Thread:get_CurrentThread():ref
[IL=?] WhereListIterator`1:.ctor(ref,ref):this
[IL=?] Iterator`1:.ctor():this
[IL=?] Object:.ctor():this
[IL=?] Environment:get_CurrentManagedThreadId():int
[IL=?] Thread:get_CurrentThread():ref
[IL=?] WhereEnumerableIterator`1:.ctor(ref,ref):this
[IL=?] Iterator`1:.ctor():this
[IL=?] Object:.ctor():this
[IL=?] Environment:get_CurrentManagedThreadId():int
[IL=?] Thread:get_CurrentThread():ref
```
Sample showing the recursive inline:
```
Inlines into Fact:factRx(int,int,int,int):int
[IL=6] Fact:factRx(int,int,int,int):int
```
|
|
|
|
Most of these tests were blocked on unnecessary usage
of SerializableAttribute and Environment.ExitCode.
|
|
These tests were thought to have been ported earlier.
|
|
The project files were generated automatically from a database
and the source files scrubbed and formatted.
In addition, some added tests are still failing. Issues were
created for these and exclusions added, for windows and for
non-windows.
|
|
This changes moves coreclr onto DNX (same version as corefx). Theoretically, this should allow these tests to target the desktop CLR. All of the old package.config files are gone and replaced with corresponding project.json files. The up front restore behavior is retained. Tests are now buildable individually, though not runnable in a similar fashion.
|
|
We spend a fair amount of time (six wall clock minutes on my machine)
doing package restore for the JIT tests. This is because each project
has its own packages.config file, so during the build we call nuget
restore for each project.
There are only four unique packages.config files for all these tests, so
this change moves them to tests/src/JIT/config and updates the project
files to consume them from there.
This means during the build the `EnsureDependencies` target does not
need to invoke nuget restore as often and the build is much faster as a
result.
|
|
This change replaces the template projects used for the ported JIT tests
with a single project file per test. This refactoring is intended to
clarify exactly which tests from the legacy testbed have been ported
and what their dependencies are; this should make later reasoning about
these tests more straightforward.
This change also disables a number of innocuous warnings in the ported
tests for hygenic purposes.
|
|
Add inlining optimizaiton test cases for JIT. Related proj, config, and sln files
added and updated. Passed build, buildtest, runtest.
|
