-
Notifications
You must be signed in to change notification settings - Fork 23
Open
Description
This is not immediate issue, but for tracking
Background:
- BinAST file encodes interface fields in IDL's order
- Given we encode scope information, at the point of reading each node, it's ready to compile the code to bytecode or machine code
- Currently IDL uses the syntax order for each field
- There are some differences between syntax order and execution order
- Some optimizations might be possible if some other fields are encoded in different order (this mostly depends on implementation)
From early experiment, I found some cases:
for (init; cond; update) body- execution order is:
init,cond,body,update
- execution order is:
switch (discriminant) { case C1: body1; case C2: body2; ... }- jump operation can be optimized if case values are all known before reading bodies
there may be other cases.
- jump operation can be optimized if case values are all known before reading bodies
on SpiderMonkey, we're going to compile BinAST file directly to bytecode, and if the IDL order matches to bytecode order, the compilation can become simpler.
to be clear, I'm trying to avoid modifying the IDL order just for SpiderMonkey's benefit, so we need to figure out other engine's situation as well.
ExE-Boss
Metadata
Metadata
Assignees
Labels
No labels