mono/mini/TODO

   1 * use a pool of MBState structures to speedup monoburg instead of using a
   2   mempool.
   3 * the decode tables in the burg-generated could use short instead of int
   4   (this should save about 1 KB)
   5 * track the use of ESP, so that we can avoid the x86_lea in the epilog
   6
   7
   8 Other Ideas:
   9
  10 * the ORP people avoids optimizations inside catch handlers - just to save
  11   memory (for example allocation of strings - instead they allocate strings when
  12   the code is executed (like the --shared option)). But there are only a few
  13   functions using catch handlers, so I consider this a minor issue.
  14
  15 * some performance critical functions should be inlined. These include:
  16         - mono_mempool_alloc and mono_mempool_alloc0
  17         - EnterCriticalSection and LeaveCriticalSection
  18         - TlsSetValue
  19         - mono_metadata_row_col
  20         - mono_g_hash_table_lookup
  21         - mono_domain_get
  22
  23 * if a function which involves locking is called from another function which
  24   acquires the same lock, it might be useful to create a separate _inner
  25   version of the function which does not re-acquire the lock. This is a perf
  26   win only if the function is called a lot of times, like mono_get_method.
  27
  28 * we can avoid calls to class init trampolines if the are multiple calls to the
  29   same trampoline in the same basic block. See:
  30
  31   http://bugzilla.ximian.com/show_bug.cgi?id=51096
  32
  33 Usability
  34 ---------
  35
  36 * Remove the various optimization list of flags description, have an
  37   extra --help-optimizations flag.
  38
  39 * Remove the various graph options, have a separate --help-graph for
  40   that list.
  41
  42 Cleanup
  43 -------
  44
  45 Clean up the usage of the various CEE_/OP_ constants inside the JIT.
  46
  47 Currently, there are the 5 variants for each opcode:
  48 - CEE_...
  49 - OP_...
  50 - OP_I...
  51 - OP_L...
  52 - OP_P...
  53
  54 Some opcodes have some variants, while others don't.
  55
  56 They are used as follows:
  57 - In method_to_ir, CEE_ means the IL opcode ie. without operand size information
  58 - In the rules inside the .brg files CEE_ means the same as OP_I..., since
  59   long opcodes were transformed into OP_L.... by method_to_ir.
  60 - In the IR emitted by the rules inside the .brg files, CEE_ means the same as
  61   OP_P..., since it is usually generated for pointer manipulation.
  62 - In mono_arch_emit_opcode, CEE_ means OP_P....
  63
  64 As can be seen above, this is a mess. A proposed solution would be the
  65 following:
  66
  67 - In method_to_ir, transform CEE_ opcodes into the appropriate OP_I/OP_L
  68   opcodes.
  69 - Get rid of the OP_P opcodes, and use the OP_... opcodes instead, since the
  70   two usually means the same.
  71 - In the IR emitted by the burg rules, use the OP_... opcodes instead of the
  72   CEE and OP_P opcodes.
  73
  74 Using these rules would ensure that the same opcode means the same thing in
  75 all parts of the JIT.
  76
  77