Improve performance of atomic load in toplevel code

[maleadt]

As noted in #47561, the performance of toplevel code is pretty bad because of the atomic barrier (loading the global world age into the task-local one) that's emitted after every instruction now. @vtjnash noted that monotonic ordering is sufficient, which recovers some performance (1.5s -> 0.7s). But the biggest improvement comes from not emitting the atomic operation between every statement, but only when we perform a call.

Fixes #47561

[vtjnash]

It was somewhat intended. I wanted to move it before every CallInstr, instead of doing it after the calls or ccalls, so that it was synchronized with any other atomic barriers written by the user

[maleadt]

We could also move these costly atomic operations to only appear before CallInst or similar such instructions, where the cost is free

I implemented that suggestion, @vtjnash.

[maleadt]

Is the linux32 GC corruption known? I don't see how it could be related...

As this is a simple performance fix for an issue that could otherwise trip up people benchmarking code in the REPL (which seems like a common thing to do), I think it would be good to back-port this to 1.8
(if we're still going to do a release before 1.9). Feel free to remove the tag if anybody disagrees.

[gbaraldi]

It might be an OOM error showing up as something else. Does retrying fix it?

[maleadt]

No, it seems to happen every time...

[maleadt]

After the rebase, CI looks better.

[vchuravy]

The 32bit windows failure is still there, as well as on other PRs rebased ontop of this (as an example https://github.com/JuliaLang/julia/commits/vc/vtune)