Oops, I think I forgot to hit "reply all". - Alon
On Thu, Dec 26, 2013 at 11:15 AM, Alon Zakai <[email protected]<[email protected]> > wrote: > > > > 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.
