[PATCH] D59251: [Documentation] Proposal for plan to change variable names

[Chris Lattner via Phabricator via llvm-commits]

lattner added a comment.

this is a really great summary of the situation, thank you for collecting this in such a methodical way!



================
Comment at: llvm/docs/Proposals/VariableNames.rst:46-47
+
+  InnerLoopVectorizer LB(L, PSE, LI, DT, TLI, TTI, AC, ORE, VF.Width, IC,
+                         &LVL, &CM);
+
----------------
t.p.northover wrote:
> WTF!
seriously :-)


================
Comment at: llvm/docs/Proposals/VariableNames.rst:90
+
+Differentiating variable kinds
+------------------------------
----------------
FWIW, I personally consider this to be a totally orthogonal discussion to the other issues, I think it would be nice to separate it out just so we have some hope of converging an already contentious topic.  Ratcheting forward one decision at a time seems like better way to make progress.


================
Comment at: llvm/docs/Proposals/VariableNames.rst:141
+============================ =============
+BasicBlock                   bb
+DeterministicFiniteAutomaton dfa
----------------
Small point, but I think that "block" is a much better name than bb in practice.


================
Comment at: llvm/docs/Proposals/VariableNames.rst:144
+DominatorTree                dt
+Function                     f
+LoopInfo                     li
----------------
mehdi_amini wrote:
> side note: I feel that single letter variable name are annoying (can't easily search in a text editor for example), I would rather use a short name like `func`.
Yeah, maybe this could include a list, like f, fn, func, etc.  There is a diversity of contractions used here.  Standardizing this is a theoretically nice thing, but a distraction from the core issue in this discussion and not particularly important in the big scheme of things (unlikely to cause confusion).


================
Comment at: llvm/docs/Proposals/VariableNames.rst:254
+
+Minimising cost of downstream merges
+************************************
----------------
FWIW, It has never been a goal for LLVM To prevent downstream merge conflicts.  The "party line" (painful as it may be in practice) is that mainline moves ahead full speed without worrying about this, and anyone adversely affected should work to get their changes merged to mainline.

This isn't likely to affect the public APIs in llvm/include in a significant way, so it really only affects people with diffs against core code.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D59251