dotnet/runtime

Enable specification of function ranges for JIT config values

Open

#13,307 opened on Aug 23, 2019

View on GitHub
 (3 comments) (0 reactions) (0 assignees)C# (5,445 forks)batch import
area-CodeGen-coreclrhelp wanted

Repository metrics

Stars
 (17,886 stars)
PR merge metrics
 (Avg merge 12d 11h) (661 merged PRs in 30d)

Description

Currently there is ifdefed out in several places in the JIT that take a low and high hash value to enable binary search for optimization or register allocation issues:

  • minoptshashlo/minoptshashhi in compiler.cpp
  • JitStressRegsHashLo/JitStressRegsHashHi in lsra.cpp
  • structpromohashlo/structpromohashhi in morph.cpp
  • loopclonehashlo/loopclonehashhi in optimizer.cpp
  • loophoisthashlo/loophoisthashhi in optimizer.cpp

Each of these does their own processing.

There's also COMPlus_JitFunctionFile that allows the specification of a file with a list of functions. It would be good to have a general mechanism to specify:

  • A range of method hash values
  • A range of method count (Compiler::jitTotalMethodCompiled) - useful when the JIT order is reasonably stable and there are many methods with the same hash and/or in combination with a range of hash values when multiple methods must be included to reproduce a failure. This was valuable in tracking down dotnet/runtime#12993.
  • A COMPlus value that is enabled only for the methods included in the set

category:implementation theme:jit-coding-style skill-level:beginner cost:small

Contributor guide

Research direction
Examine existing ifdefed code patterns for hash ranges. Propose a unified configuration struct that accepts method hash range and method count range, and use it across all JIT components. Add corresponding COMPlus environment variables like COMPlus JitMethodHashRange and COMPlus JitMethodCountRange. Implement in compiler.cpp, lsra.cpp, morph.cpp, optimizer.cpp by replacing the duplicated logic.
Tech stack
cpp
Domain
backend
Issue type
Feature
DifficultyEstimated implementation difficulty for a new contributor, from 1 for very small changes to 5 for expert-level work.
2
Estimated timeA rough time range for an experienced contributor to investigate, implement, test, and prepare a pull request.
1-3 hours
Activity statusHow available the issue appears right now: fresh, active, stale, blocked, or waiting on maintainer input.
Active
ClarityHow clearly the issue explains the expected change, acceptance criteria, and next step.
Clear
Prerequisites
GitC++
Newbie friendlinessA 1-100 score estimating how approachable this issue is for first-time contributors.
75