sivadeilra wrote: @efriedma-quic - I'm looking at several approaches for handling this, but before I go too far with it, it would help to know just how general or complete the solution needs to be. The problem is that the transformation I'm doing will necessarily change a constant expression tree into a non-constant expression tree. So every time I find a reference to a global variable that is inside a constant expression, I will need to rewrite it to point to the load instruction, and rewrite its caller (and that caller...) until I reach a non-constant user.
I'm thinking that the way to do this is to iterate through instructions, then recursively walk every operand and look for `GlobalVariable` references. If I find any `ConstantExpr` operands, then I'll recursively descend into that `ConstantExpr` and look for `GlobalVariableVal` and `GetElementPtr` constant expressions. My questions for you: * Is rewriting these constant expressions trees sufficient? * Will the results be well-formed? * How many different cases will this need to cover? Our hot-patching tools disassemble instruction streams and look for references to global variables that the compiler did not transform into `__ref_*` indirections. So if we don't match some particular case, we should still catch it and reject the patch. Rejecting the patch is better than generating invalid code, of course. In this first PR, I'm mainly looking for getting the `S_HOTPATCHFUNC` generation in place, and covering the 95% cases, which access an ordinary global variable. Handing a field dereference or an array dereference, both of which should show up as GEPs, should be sufficient, right? https://github.com/llvm/llvm-project/pull/138972 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
