Ehren's Blog

More analysis troubleshooting

Posted in Seneca by ehren on December 9, 2009

I wrote a little Dehydra script to determine why my optimization has resulted in a mediocre size reduction. As I suspected, most of the call sites are of the form return call(); but I can now confirm this with this script:

function isAlwaysZero(c)
  if (!c.attributes)
    return false;
  for each (let a in c.attributes)
    if ( == 'user' && a.value == 'NS_alwayszero')
      return true;
  return false;

function process_function(decl, body)
  // for calls that are simply returned
  let boringCalls = 0;
  // for calls where the return value is assigned to a variable
  let interestingCalls = 0;

  for (v in iterate_vars(body)) {
    if (v.isFcall && v.isReturn && isAlwaysZero(v))
      // the function call is returned
    else if (v.assign && v.assign[0].isFcall && isAlwaysZero(v.assign[0]))
      // the function call is assigned to a variable

  if (interestingCalls == 0 && boringCalls > 0)
    warning("boring alwayszero function (boring calls: " + boringCalls +
            "). name: " +, decl.loc);
  else if (interestingCalls > 0)
    warning("interesting alwayszero function (interesting calls: " +
            interestingCalls + ", boring calls: " + boringCalls + "). name: " +
  , decl.loc);

There may be a couple of corner cases I’m excluding here eg something like if (call()) but this should take of every instance when NS_FAILED is involved.

Anyway, here are the results:

The number of interesting call sites ie places where the return value of the call is assigned to a variable is only 67. Surprisingly, the number of boring call sites ie places where the return value of the call is simply returned is a whopping 2495. Here’s the results for all the boring callsites and all the interesting callsites, if you’re interested.

One thing I’m a bit confused about is that although there are 2495+67 = 2562 call sites where my plugin should be invoked, it is only being invoked 1305 times, which I have previously reported here (I can also confirm this from running a Mozilla build with -fdump-tree-all). Whatever the answer though, I’m pretty certain that the poor results are due to a small number of checks made on calls to functions I have patched.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: