On Thu, Dec 26, 2013 at 3:36 AM, Mark Seaborn <[email protected]> wrote:
> Hi Alon, > > I've been thinking about upstreaming PNaCl's LLVM IR simplification passes > to LLVM, which would be useful for Emscripten if you're going to reuse > these passes for Emscripten's new backend ( > https://github.com/kripken/emscripten/wiki/LLVM-Backend). > > Which of the passes do you think we should upstream first? Which are most > useful to Emscripten? I expect it will be easier to make the case for > upstreaming a pass if it is used by both PNaCl and Emscripten. :-) > Overall, the new backend uses all the passes almost like PNaCl does. That seems simplest for two reasons, first it avoids needing to fiddle with passes and their dependencies (if we remove one pass, we might find another that we need does need it), and second it means PNaCl and emscripten generate more similar code, which could help things like pepper.js and in general projects that port using both PNaCl and emscripten. There are only a few changes emscripten currently does ( https://github.com/kripken/emscripten-fastcomp/blob/master/lib/Transforms/NaCl/PNaClABISimplify.cpp): * We disable ExpandTls since we don't need it, no threads * We disable ExpandSmallArguments because we don't need to worry about undefined behavior (JS makes it defined), and I saw it show up on profiling data. But perhaps that was just one specific workload, probably would do no harm to restore it. * We disable RewriteAtomics, and just use the llvm intrinsics for which we already have JS to implement, and can ignore volatile due to not having threads. * We disable StripAttributes, because we benefit from the alignment info it removes, in load/store, memory intrinsics, as well as functions (better packed function tables). Finally, * We add an ExpandI64 pass which lowers operations on i64s (bitcasts, additions, shifts, etc.) into operations on pairs of i32s, and when necessary calls into emscripten's existing runtime support functions (e.g. for multiplication and division, which we do not just inline code for). Overall, we use almost all the passes without changes, except for the few mentioned above. So upstreaming pretty much all of them seems to make sense to me, but I'm unsure how that process works, how much effort it takes, etc.? More comments below. > > Here's a list of PNaCl's IR simplification passes, in decreasing order of > what I'm guessing their usefulness to Emscripten would be. > > These are probably useful in any case: > * ExpandCtors > * PromoteIntegers > * ExpandArithWithOverflow -- I don't think Emscripten can optimise these > better, unless new operations are added to Javascript? > Yes, that's correct, can't do any better anyhow. > * ExpandStructRegs > * ResolveAliases > > These two would be useful for initial bring-up, though I suspect > Emscripten could produce slightly more efficient code by the stack pointer > explicitly (which PNaCl can't do because it doesn't have an explicit stack > pointer): > * ExpandVarArgs > * ExpandByVal > Not sure we can do better, we need to store varargs on the C stack anyhow because people can access them in low-level ways (va_arg), so we can't put them on the JS stack which we do for non-varargs calls and which is faster. So what ExpandVarArgs does is reasonable (although not optimal in terms of alignment for us I think, but I didn't look into it, varargs tends not to be that important for performance in my experience). I haven't looked carefully at ExpandByVal's output yet. But we do have benchmarks on byval struct passing, and they seem fine. > > These might allow the backend to be a little simpler: > * FlattenGlobals -- simplifies later lowering? > * ExpandConstantExpr -- simplifies later lowering? > * ExpandGetElementPtr -- a minor help > * CanonicalizeMemIntrinsics > * ReplacePtrsWithInts -- might only be useful for the explicit > trunc/zexts it inserts (to avoid casts between pointers and non-i32 ints), > which could be done by a simpler pass > > Yes, these are all nice in that they make lowering simpler. In theory emscripten could use something even simpler and specific for it, but as I said earlier, nice to use the same code between our projects, to make code ported by both more similar and compatible, and to avoid duplication of effort. - Alon -- 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/groups/opt_out.
