Hmm yes, those other temporaries might need to be spilled too. You can use reg2mem for that. That might be the simplest thing. In fact you can optimize normally and just do reg2mem at the very end, as one option.
Alternatively, yeah, this is somewhat similar to register spilling code. Note though that the asm.js backend doesn't use any register spilling at all, or the common backend codegen. I don't think moving that code around would be easy. Instead, you might just write that pass that directly does that "spilling" around calls. I think to be sure of this working you'd need to ensure those writes aren't optimized out. Making them volatile might help, but the call might be optimized to another location. (Perhaps you'd need a special intrinsic call after the stores and another after the call, so that the optimizer must preserve that sequencing.) On Fri, Aug 4, 2017 at 2:28 PM, William Maddox <[email protected]> wrote: > Thanks for taking the time to reply. > > The code is just way too undisciplined to rely on either source > modification or identification of pointers by type. Many pointers are > stored as uintptr_t or equivalently-sized int and unsigned values. I > previously considered scanning only between frames, and don't think it > would work for us. Deferring GC itself only increases memory footprint, > but we also use a deferred reference counting scheme that relies on > frequent purges of its zero-count table. > > Suppressing mem2reg is an intriguing possibility. From what I understand, > however, front-ends allocate user-declared variables using alloca, but most > temporaries, such as needed during expression evaluation, are left as > variables in the LLVM IR. These temporaries also need to be made visible > to the stack scanner. > > Assume for a moment that we have the LLVM IR in full SSA form, with > mem2reg having run and phi nodes inserted as necessary. I would like to > insert, prior to each function call, a store into the explicit stack of the > value of each IR variable that is live at the call, unless the call is > dominated by an identical store. > > The task seems very similar to generating register spills around function > calls in a caller-saves discipline, except that reloading is not > necessary. I was hoping that there was a simple way to re-use existing > register allocation code to accomplish this. But perhaps I just need to > bite the bullet and write a new pass that performs the transformation > outlined in the previous paragraph. > > Comments? > > >> -- > 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.
