[PATCH] [FaultMaps] Let the frontend pre-select implicit null check candidates.

Joseph Tremoulet jotrem at microsoft.com
Mon Jun 29 18:31:03 PDT 2015


Some questions about the direction:

1 - How early/late do you expect the frontend to insert these annotations?  If it's early, isn't there a very real chance that the annotations will get dropped/misplaced during optimization?  Conversely, if it's late, isn't it going to be difficult for the frontend to correlate the IR to the side information you're expecting it to use?
[I understand it won't be a correctness issue either way, but the performance issue seems real.]

2 - I anticipate that for LLILC we'll want this to be profile-driven -- we don't have healing, but typically (in other .Net JITs) use machine faults anyway for the null checks that are implicit in MSIL instructions because we're comfortable assuming that their failure rate is effectively zero; so I'd expect that our reader will annotate branch profiles with that assumption, that optimizations will make a reasonable effort to propagate the branch profiles (please correct me if that's a bad assumption), and that we'll then want to consume that information for the implicit null check optimization.  It seems like that approach will be perfectly compatible with this change if we simply add a pass that LLILC can opt into / you can opt out of that runs just before implicit null check optimization which annotates super-cold checks as !make-implicit.  So my questions are
 2a - Does that approach sound feasible to you?
 2b - Was your change of direction simply because you think you'll get better performance this way, or are there any issues with using profile information that you're aware of that we'll run into if we add a pass like I just described?

[Of course, if metadata annotations are more robust than I'm imagining, #2 is a non-issue and we can just annotate branches appropriately when we initially generate LLVM IR.]

The code itself looks good to me given the direction.


http://reviews.llvm.org/D10824

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/






More information about the llvm-commits mailing list