[PATCH] D82941: [StackSafety,NFC] Update documentation

[Vitaly Buka via Phabricator via llvm-commits]

vitalybuka marked an inline comment as done.
vitalybuka added inline comments.


================
Comment at: llvm/docs/LangRef.rst:6857
+parameter. ``calls`` is empty, so the parameter is either not used for function
+calls or ``offset`` already covers all accesses from nested function calls. Then
+function itself can access just a single byte of the parameter #3. Additional
----------------
tejohnson wrote:
> nit: s/Then/The/
> 
> I assume if it is passed directly to another call and we don't know the accesses within that callee (this is the per-module summary) that it would have a calls entry with offset [0,0]? 
> I assume if it is passed directly to another call and we don't know the accesses within that callee (this is the per-module summary) that it would have a calls entry with offset [0,0]?

calls list is only needed when we don't know accesses inside of callee. If we know accesses we can directly apply them to offset of parameter (offset: [5, 5])
if we don't know accesses we still know offset used to pass the parameter
I've added function body into the example.


================
Comment at: llvm/include/llvm/IR/ModuleSummaryIndex.h:557
+  /// Describes the uses of a parameter by the range of byte offsets of direct
+  /// access in in the function and by all of the call targets it is passed to.
   struct ParamAccess {
----------------
tejohnson wrote:
> nit: s/in in/in/
> 
> The "by all of the call targets it is passed to" sounds ambiguous to me, as if we already have knowledge of how it is accessed within those callees. I guess this is the situation after the thin link, but not initially.
> 
> Probably best to be more explicit. I.e., from my understanding reading your LangRef writeup:
> - In the per-module summary, the Calls vector summarize the byte offset applied to each pointer parameter before passing to each corresponding callee. I.e. this structure describes offsets computed from the pointer parameter within the function only
> - In the combined summary, the offsets may include the offsets within each called function consuming this pointer parameter. Two questions: I assume that happens after some kind of inter-procedural propagation across the combined summary? After that propagation, is the Calls list empty?
I moved this description close to fields.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D82941