If it's feasible, then the best option is changing the source code. Each pointer could be held in a HeapifiedPointer class instead, where that class has a volatile pointer and accesses go through it. That would ensure it's on the heap.
Another option is if you can wait until between frames to scan for pointers. In between frames nothing would be in JS variables. If those aren't practical, then another option is to just not optimize the code. clang puts things on the stack (allocas) by default anyhow, and it's the LLVM optimizer which turns them into registers (mem2reg). So in principle your app might work just fine if all source files are compiled with -O0. Would be a big slowdown, but should work. It might be possible to try to get the optimizer to leave pointers alone while optimizing everything else. You might try to modify mem2reg that way, in fact. However, I believe LLVM is moving to get rid of pointer types, which might make this impossible eventually. It might be worth talking to upstream LLVM about this. Might also be worth checking what happens if you run all optimizations except for mem2reg. Probably it would help speed a little and not break things, but I think most opts do depend on mem2reg having run to be effective. There might also be a way to modify clang to do this. It does know which variables are pointers, so you could perhaps make their loads and stores of their allocas be volatile. On Thu, Aug 3, 2017 at 3:30 PM, William Maddox <[email protected]> wrote: > > I am attempting to port a large C++ program that requires scanning the C++ > stack (conservatively) for pointers. I am looking to modify > emscripten-fastcomp to maintain the necessary state on the explicit stack > (e.g., in HEAP32). Values stored in JS variables, i.e., which would > normally reside only on the implicit JS stack, need to be copied to the > explicit stack such that the copies are up-to-date at each procedure call. > This is similar in spirit to spilling registers around procedure calls, > but the values must be stored in linear memory where the stack scanning > code can get at them, and there is no need to reload from the "spilled" > slots, as the JS engine will keep its own copy. Note that what is required > here is a bit more than would be needed for supporting a naive debugger, as > temporary variables that are not named in the C++ source code need to be > spilled as well. > > Has anyone been down this road before? I am fully prepared to jump into > the LLVM code, but I'd like to avoid false starts and blind alleys if > possible. In particular, any documentation or notes on the internals of > emscripten-fastcomp, particularly with respect to points of commonality and > divergence with more conventional LLVM targets, would be most helpful. > > I expect there will be a significant performance penalty for generating > code in this way, but there are likely others similarly situated who would > benefit from a compiler mode that could support stack scanning. I'd be > happy to contribute anything I come up with back to the project. > > Thanks, > > --Bill > > -- > You received this message because you are subscribed to the Google Groups > "emscripten-discuss" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "emscripten-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
