ymandel added a comment.

Thanks for clarifying the issues here.  A few thoughts:

1. Thanks for clarifying about the blank lines. I was wondering how to read 
that and I think that fills in an important missing detail for me.

2. I'm particularly interested in the case of tuple-like containers, which is a 
little different (though I think the same point holds):

Example: https://godbolt.org/z/qcWMdG33T

  #include <tuple>
  std::tuple<bool, int> mk();
  
  void f() {
    auto [b, i] = mk();
    (void)i;
  }

CFG:

  void f()
   [B2 (ENTRY)]
     Succs (1): B1
  
   [B1]
     1: mk
     2: [B1.1] (ImplicitCastExpr, FunctionToPointerDecay, std::tuple<_Bool, 
int> (*)(void))
     3: [B1.2]() (CXXRecordTypedCall, [B1.4])
     4: auto = mk();
     5: get<0UL>
     6: [B1.5] (ImplicitCastExpr, FunctionToPointerDecay, typename 
tuple_element<0UL, tuple<_Bool, int> >::type &&(*)(tuple<_Bool, int> &&) 
noexcept)
     7: 
     8: [B1.7] (ImplicitCastExpr, NoOp, std::tuple<_Bool, int>)
     9: [B1.6]([B1.8])
    10: std::tuple_element<0, std::tuple<bool, int>>::type b = get<0UL>();
    11: get<1UL>
    12: [B1.11] (ImplicitCastExpr, FunctionToPointerDecay, typename 
tuple_element<1UL, tuple<_Bool, int> >::type &&(*)(tuple<_Bool, int> &&) 
noexcept)
    13: 
    14: [B1.13] (ImplicitCastExpr, NoOp, std::tuple<_Bool, int>)
    15: [B1.12]([B1.14])
    16: std::tuple_element<1, std::tuple<bool, int>>::type i = get<1UL>();
    17: i
    18: (void)[B1.17] (CStyleCastExpr, ToVoid, void)
     Preds (1): B2
     Succs (1): B0
  
   [B0 (EXIT)]
     Preds (1): B1

Here, both lines 7 and 13 are blank but seem to be the underlying tuple that's 
being deconstructed.  Are these different instances of the DecompositionDecl or 
are they (unprinted) references back to line 4?

3. I'm still bothered that this seems to violate the design/philosophy of the 
CFG, which I take as ensuring that elements proceed in the order of operation. 
I see the problem here -- that the AST includes backedge, but can we solve it 
by adding another synthesized element for the object being deconstructed? Or, 
perhaps we could add new CFG kind that marks the appearance of the 
DecompositionDecl an extra time? That is, first time is so that the 
DecompositionDecl can be referenced as it is now, but second time is so that 
the statement can be evaluated in the proper order (after all of its 
constituent elements)?

Finally, a nit: why doesn't line 13 in your example, and lines 7 and 13 in my 
example, print? Is that something that I could add to the CFG printer?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D139544

_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to