FW: Help understanding r127440

It appears Mr. Cheng may be busy, so perhaps someone here knows?

I’ve been debugging a code generator bug that surfaced while trying to build tinyXML for ARM with LLVM 2.8. The bug seems to originate in DAGCombiner. LLVM 2.9 still has this bug, but top of trunk does not. To narrow down what change fixed it, I’ve used a binary search of revisions from 2.9 to top of trunk. The bytecode compiles once I back ported r127440 to LLVM 2.8. Hurray! But I don’t understand why it fixes my bug.

I’d love to know more. Especially, I’d like to produce a C/C++ snippet which repros the problem on a small scale.

Your revision description indicates “Avoid replacing the value of a directly stored load with the stored value if the load is indexed. rdar://9117613.”

I’ve tried a variety of weird pointer manipulations like those found in tinyXML e.g. *p = *(p + 1), *(p+1) = *p. But none of my attempts seem to get it to fail the way my input bytecode failed.

I’m trying to understand what 2011-03-10-DAGCombineCrash.ll is testing, and I don’t really fully read LLVM bytecode yet. If it is possible, could you’d be so kind as to share a C/C++ snippet? Or if you have the time, maybe share with me how the fix addresses the bug, and what the original bug was. I don’t believe I have any visibility into rdar://9117613.

Attached is the bytecode which will break LLVM 2.8 – 2.9 with:

Stack dump:
0.      Program arguments: llc libtinyxml.so.bc
  1. Running pass ‘Function Pass Manager’ on module ‘libtinyxml.so.bc’.

  2. Running pass ‘ARM Instruction Selection’ on function

@_ZN11PVTiXmlNode8IdentifyEPKc15PVTiXmlEncoding

Program llc died with signal 6

Thanks for your help!!

Cheers,

Joe Abbey

Software Architect

Arxan Technologies, Inc.

1305 Cumberland Ave, Ste 215

West Lafayette, IN 47906

W: 765-889-4756 x2

C: 765-464-9893

jabbey@arxan.com

www.arxan.com

libtinyxml.so.bc (102 KB)

The quick summary of r127440 is just that indexed loads produce 3
results, and the transformation in question crashed before because
it's trying to replace three values with two.

The transformation affects constructs where there is a store
immediately followed by a load from the same location, where the load
optimized to update the operand register; it's sort of tricky to
trigger reliably with C code.

If you want to reduce your bit code, you can use bugpoint
(http://llvm.org/cmds/bugpoint.html).

-Eli