conrade-ctc wrote: > I am not sure I understand where claude is going with these changes. I think > we need first some level of design sketch as that's a feature that's not > popular and likely ai will get its design wrong. For example, we need to > store some of the information in the PTU itself which can be used as an undo > starting point. > > I am not sure I also understand the codegen changes part, yet either...
The intent here was to fix isolated failures, not to address the more general undo framework, though since this is actively being worked by others afaik, this naturally increases the scope/impact and a question about design. I didn't really want to derail that discussion, and want to be sensitive about overcomplicating this "fix", but if you're concerned that we're krufting up or complicating other on-going work, seems right to work on the design more first. However, I not in that loop right now and haven't done my homework about where you are more generally for the undo work... is there a working design already for it, or are we starting that here :) FYI, here's the context from our world just to be clear: we're starting to hit this part of the jit functionality via `CppInterOp` in our formal verification pathway. As part of that iteration, we jit -> IR to figure out read/write/readwrite effects because c++ lies at the signature level (via obvious mutable semantics, but deeper pointer and handle semantics as well). I stumbled on this failure case which requires a restart of the interpreter due to the inability to properly undo when a compile fails on a probe that we send in... the fix here was intended to enable the probe to fail gracefully in that case, and undo just that failed step, and then continue without restarting the interpreter (or just choose to error out). https://github.com/llvm/llvm-project/pull/226253 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
