[llvm-dev] Renaming passes

Matt Arsenault via llvm-dev llvm-dev at lists.llvm.org
Wed Jun 24 11:21:09 PDT 2020



> On Jun 24, 2020, at 14:13, Arthur Eubanks via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> Hi,
> 
> As part of new pass manager work, I've been trying to get something like `opt -foo` working under the NPM, where `foo` is the name of a pass.
> 
> In the past there's been no reason to keep the names of passes consistent between NPM and legacy PM. But now there is a reason to make them match, so that we don't have to touch every single test that uses `opt`.
> 
> There are a couple of names that don't match though, for example the "basic alias analysis" pass is named "basicaa" under the legacy PM
> INITIALIZE_PASS_BEGIN(BasicAAWrapperPass, "basicaa",
>                       "Basic Alias Analysis (stateless AA impl)", true, true)
> but named "basic-aa" under the NPM
> FUNCTION_ALIAS_ANALYSIS("basic-aa", BasicAA())
> . Almost all the other AA passes have a dash in them so I think it makes sense to rename "basicaa" -> "basic-aa".
> 
> Is there accepted wisdom on renaming pass names? Is a pass name a stable interface? When is it ok to rename a pass? If there are 800 usages of a flag, should I rename them atomically?


I think the pass naming scheme needs a lot of work. The naming conventions seem random at times. For instance, I can never remember how to refer to PrologEpilogInserter. The DEBUG_TYPE name is “prologepilog”, the pass class name is “PEI”. I would expect this to be prolog-epilog-inserter to match the file and formal pass name, and consistently use dashes as word separators.

Unfortunately, I recently discovered some optimization pass remarks expose pass names to the user (since you use the name of the pass to filter relevant remarks). I’m not sure how stable this is supposed to be though.

-Matt


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200624/0f2f9cdb/attachment.html>


More information about the llvm-dev mailing list