[llvm-dev] the Univac 2200, LLVM, and national security

[Sanjoy Das via llvm-dev]

Please stay on the original thread -- I've addressed your concern there.

On Wed, Jun 28, 2017 at 11:35 PM, Peter Lawrence
<peterl95124 at sbcglobal.net> wrote:
> John,
>          One of my previous jobs was at Unisys doing a dynamic translator
> for the Univac 1100 / 2200 series computers.  We chose LLVM for the base
> of the translator for its modularity, optimizations, and x86 code generation.
> We wrote a front-end that parsed Univac instructions and generated IR
> for them. It all ran on X86-Linux boxes which with some special peripheral
> adaptors were then plug-in replacements for Univac hardware.
>
> You might be wondering what anyone was doing with the very ancient and
> very decrepit Univac computer, which it turns out is a very interesting question.
>
> The problem is that no one at Unisys knows for sure what was being done with
> Univac computers because it is classified top secret information, no one at Unisys
> had that clearance, and if they did they couldn’t talk about it.
>
> But there was plenty of speculation. The Univac computer was popular around
> the time of the start of the Cold War, so most folks believed there are Univac
> computers that are running our nuclear missiles and our strategic defense,
> that for various reasons can’t be upgraded. In particular some of the source
> code no longer exists, hence the need for a dynamic translator to execute
> the existing binaries.
>
> So where is this discussion going, another great question.
>
> Now imagine that somewhere in these Univac binaries, for which source code
> no longer exists, there is something that translates to something like
>         foo (int a) {
>                 if (a == a)
>                         S;
>         }
> I know it is a stretch, but imagine this is the result of some other optimizations,
> and suppose that ‘a’ ends up “undef”, by some other sequence of optimizations,
>
> Then it is possible that in spite of the intention that statement ’S’ always gets
> executed, this can’t be guaranteed in the current LLVM.
>
>
> So the question about what the compiler should do in the case of function-
> inlining suddenly isn’t so academic, it is possible that our current nuclear
> missiles and strategic defense actually require a consistent behavior.
>
>
> So I hope you will join me in thinking LLVM should exhibit consistent behavior
> in these sorts of situations, regardless of what might be allowed by the C
> standard.
>
>
> Peter Lawrence.
>
>
>
>
>