Do not unnecessarily mark local variables static

[tautschnig]

No description provided.

[allredj]

This PR failed Diffblue compatibility checks (cbmc commit: 7191f23).
Build URL: https://travis-ci.com/diffblue/test-gen/builds/77256446
Status will be re-evaluated on next push.
Please contact @peterschrammel, @thk123, or @allredj for support.

Common spurious failures:

• the cbmc commit has disappeared in the mean time (e.g. in a force-push)
• the author is not in the list of contributors (e.g. first-time contributors).

[smowton]

At least for the strings I'd guess the compiler will construct it once per function call vs. only on first call? It seems like this could only make things worse than static const

[tautschnig]

It seems like this could only make things worse than static const

I'm not sure I agree: static locals introduce a branch (to test whether initialization is necessary) on each invocation and, at least for GCC (and possibly also VS, if C++11 is fully implemented), setting up a mutex to avoid deadlocks.

For sure I'm not going to insist on getting this PR in in its current form, but this rather random sprinkling of static is an attempt at optimisation that I doubt is backed by data?!

[tautschnig]

In line with my above comment: the assembler output of compiling

#include <string>

int main(int argc, char *argv[])
{
  static const std::string bla = "bla";
  return bla == argv[0];
}

vs. the same while removing static confirms my above statement. But of course that in itself isn't sufficient to show any performance gain or loss.

I'd say: if you seriously want a constant of static lifetime for performance reasons, you might as well declare a file-local global constant.

[smowton]

The one reason I rarely do that is for static const irep_idt, which must be init'd after the string table -- on first use of a particular function is a convenient way to achieve that, without risking the same string-to-irep_idt conversion happening frequently.

Still as you say, it's not like I have any data one way or the other, so not blocking this.

[kroening]

The non-static variant tends to be more optimisation-friendly, I believe (no hard data either).
Let's go for it.