I narrowed down the miscompilation of openssh to a single function, which
bugpoint most helpfully reduced to the instcombine pass. (I don't know what was
going on before when I thought I was using llvm-as instead of gccas. But anyway.) 

I will attach the bytecode for the test program, which is supposed to output
"0x0\n". This particular zero is supposed to be the input to a kind of
shift-register-like thing, so if you get that first byte wrong, the subsequent
bytes have no hope.

The before-and-after diffs are pretty stark... instcombine has replaced my usual
tasty pointer arithmetic with something which is definitely much worse than
Folgers Crystals. 

445 zion> diff -u testprogramE.unopt.ll testprogramE.opt.ll
--- testprogramE.unopt.ll       2003-11-12 01:22:43.000000000 -0600
+++ testprogramE.opt.ll 2003-11-12 01:23:08.000000000 -0600
@@ -26,9 +26,8 @@
        %tmp.7 = cast sbyte %tmp.6 to int               ; <int> [#uses=1]
        %tmp.3 = call sbyte* %strchr( sbyte* getelementptr ([4 x sbyte]*
%.Base64_1, long 0, long 0), int %tmp.7 )             ; <sbyte*> [#uses=1]
        %tmp.8 = cast sbyte* %tmp.3 to int              ; <int> [#uses=1]
-       %tmp.9 = cast int %tmp.8 to sbyte               ; <sbyte> [#uses=1]
-       %tmp.12 = sub sbyte %tmp.9, cast ([4 x sbyte]* %.Base64_1 to sbyte)    
      ; <sbyte> [#uses=1]
-       %tmp.13 = cast sbyte %tmp.12 to ubyte           ; <ubyte> [#uses=1]
+       %tmp.9 = cast int %tmp.8 to ubyte               ; <ubyte> [#uses=1]
+       %tmp.13 = add ubyte %tmp.9, 9           ; <ubyte> [#uses=1]
        %tmp.14 = shl ubyte %tmp.13, ubyte 2            ; <ubyte> [#uses=1]
        %tmp.15 = cast ubyte %tmp.14 to int             ; <int> [#uses=1]
        %tmp.1 = call int (sbyte*, ...)* %printf( sbyte* getelementptr ([6 x
sbyte]* %.str_2, long 0, long 0), int %tmp.15 )           ; <int> [#uses=0]

Created an attachment (id=20) [details]
test program.

The desired output from the test program is "0x0\n".

Note that this is not a bug in the instcombine pass.  Instcombine is innocently
making LLVM code which the bytecode reader/writer cannot correctly preserve. 
There is something horribly wrong in one of the SlotCalculator, Bytecode Reader
or Bytecode Writer.

Here's an updated testcase:
http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20031110/009421.html

-Chris

Better yet, this:
%.Base64_1 = external constant [4 x sbyte] 

ubyte %test() {
        ret ubyte cast (sbyte sub (sbyte 0, sbyte cast ([4 x sbyte]* %.Base64_1
to sbyte)) to ubyte)
}

Assembles and disassembles to:
ubyte %test() {         ; No predecessors!
        ret ubyte 2
}

phear the optimizer!!

-Chris

This bug is now fixed:
http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20031110/009516.html

Long live openssh,

-Chris