[PATCH] Bug in SimplifyDRTCalls breaking array appending

I did all my tests on linux x86_64.

generating a .bc file and optimizing it (as suggested by Deewiant) works (both with and without -inline and -release)

ldc -c -output-bc tango/core/rt/compiler/util/utf.d
if opt -O3 utf.bc > utf2.bc ; then echo 1 ; fi

but the direct optimization

ldc -c -O -output-bc tango/core/rt/compiler/util/utf.d

fails.

As the error is triggered by an assertion of llvm it happens only if one has compiled llvm with --enable-assertions . The release version will ignore this error (rubenbb has no error with this on FreeBSD).

disabling the d passes

ldc -c -O  -disable-d-passes tango/core/rt/compiler/util/utf.d

the file compiles, which shows that some of the D specific passes are the culprit here (not llvm).

Raising priority to blocker as the reduced test case shows that this is a very serious issue:

void foo() {
   char[] str;
   str ~= "[";
}

The issue is caused by the SimplifyDRTCalls pass – somehow it manages to produce invalid IR in combination with at least another standard optimization pass, leading to this:

Error: Stored value type does not match pointer operand type!
  store i8 91, i8* (%object.TypeInfo*, i64, i64, i8*)* @_d_arraysetlengthiT, align 1
 i8* (%object.TypeInfo*, i64, i64, i8*)
Broken module found, compilation terminated.

The assert in Value::replaceAllUsesWith is no longer triggered, but I'm fairly confident that this is the same issue (the test-case was actually reduced from tango.text.Regex, because tango/core/rt/compiler/util/utf.d compiled fine for me).

Oh, I didn't mean to change the owner of this ticket, no idea how this happened…

When comparing the IR dumps before and after the pass is run, the problem becomes obvious:

*** IR Dump After Global Value Numbering ***
define fastcc void @_D5regex3fooFZv() {
entry:
  %.gc_mem = tail call i8* @_d_arraysetlengthiT(%object.TypeInfo* @_D11TypeInfo_Aa6__initZ, i64 1, i64 0, i8* null)
  store i8 91, i8* %.gc_mem, align 1
  ret void
}
*** IR Dump After Simplify calls to D runtime ***
define fastcc void @_D5regex3fooFZv() {
entry:
  store i8 91, i8* (%object.TypeInfo*, i64, i64, i8*)* @_d_arraysetlengthiT, align 1
  ret void
}

Oops…

Turns out that this (at least) was a rather astonishing off-by-one error:

diff -r d8966356d012 gen/passes/SimplifyDRuntimeCalls.cpp
--- a/gen/passes/SimplifyDRuntimeCalls.cpp	Sat Jan 01 12:00:39 2011 +0000
+++ b/gen/passes/SimplifyDRuntimeCalls.cpp	Sun Jan 02 03:36:07 2011 +0100
@@ -126,9 +126,9 @@
         if (CI->use_empty())
             return CI;
 
-        Value* NewLen = CI->getOperand(2);
+        Value* NewLen = CI->getOperand(1);
         if (Constant* NewCst = dyn_cast<Constant>(NewLen)) {
-            Value* Data = CI->getOperand(4);
+            Value* Data = CI->getOperand(3);
 
             // For now, we just catch the simplest of cases.
             //
@@ -142,7 +142,7 @@
                 return Data;
 
             // If both lengths are constant integers, see if NewLen <= OldLen
-            Value* OldLen = CI->getOperand(3);
+            Value* OldLen = CI->getOperand(2);
             if (ConstantInt* OldInt = dyn_cast<ConstantInt>(OldLen))
                 if (ConstantInt* NewInt = dyn_cast<ConstantInt>(NewCst))
                     if (NewInt->getValue().ule(OldInt->getValue()))

I am not sure how this bug could survive for almost two years (since the very beginning of SimplifyDRTCalls to surface just after the move to LLVM 2.8 – if I had to guess, I'd say that this code path was simplify never taken until some more sophisticated optimizations in LLVM 2.8 started to simplify the IR enough for this pass to become active…

Fixed in changeset 0cb1edbcae87.