On 26 December 2013 11:15, Alon Zakai <[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.
>
OK, let's aim to upstream the bulk of the passes.
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.
>
For what it's worth, I'll give an example of what I was referring to.
Consider this C code:
struct S {
int x, y;
};
struct S pair = { 10, 20 };
foo(pair);
Currently ExpandByVal will convert that to something like this:
STACK -= 8; // Function prologue, assuming stack grows down
var pair = STACK; // Address of alloca
HEAP32[pair >> 2] = 10;
HEAP32[(pair + 4) >> 2] = 20;
foo(pair);
The alternative is to convert it to something like this:
STACK -= 8;
HEAP32[STACK >> 2] = 10;
HEAP32[(STACK + 4) >> 2] = 20;
foo();
This has the minor benefit of passing one fewer argument to foo(), so the
argument doesn't have to be computed and put into a register on x86-64 or
onto the call stack on x86-32. This might add up if there are multiple
by-value arguments, if the code is hot, etc. But this may well be too
minor to be worth optimising. I'm not going to complain if you want to
keep Emscripten closer to how PNaCl works here. :-)
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.
>
Sounds good to me.
Cheers,
Mark
--
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.
