[PATCH] D113030: Add a new tool for parallel safe bisection, "llvm-bisectd".

[Quentin Colombet via Phabricator via llvm-commits]

qcolombet added a comment.

> I'm also guessing that you'd want to avoid using string keys for the function-attribute implementation?

Yeah the string keys are not ideal since that's difficult to know what we're dealing with at that point. If I were to switch to this API, I would need to know the module ID (that we insert before hand), the function, and the instance of the optimization (e.g., is it the first invocation of InstCombine, the second etc.) to read the right annotation.
That may prove difficult to have something general here.

Perhaps we could give the bisect client the context of what is being optimized (e.g., the module for module passes, the module and the function for function passes (or just the function since the module can be found from the function), the module, the function and the loop for loop passes, etc.) and where in the pipeline we are (e.g., the pass ID) and hide the formation of a string key within the bisect client API.

The bonus side effect, is that the bisect client could handle the multi instances of passes by itself (e.g., assuming the module as a unique ID set just once, we could use this ID and the passID to know which instance of the pass is running: the bisect client could keep a count of how many times it saw that pair.)

Note: For the context, for us, the path of a file is not a good discriminant because we compile directly in-memory (the front-end generates the IR in memory and don't write it to a file) so all modules have the same path (empty). Therefore, that context, the string keys, as shown in the GISel pass (https://reviews.llvm.org/D113031), would just yield the same key over and over across different modules for all the functions with the same name (like `main`).

Cheers,
-Quentin


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D113030/new/

https://reviews.llvm.org/D113030