llvm dev - Jul 2011 - [LLVMdev] 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 at arxan.com

www.arxan.com <http://www.arxan.com/> 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20110711/ec97ee95/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: libtinyxml.so.bc
Type: application/octet-stream
Size: 104732 bytes
Desc: libtinyxml.so.bc
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20110711/ec97ee95/attachment.obj>

On Mon, Jul 11, 2011 at 1:06 PM, Joe Abbey <jabbey at arxan.com>
wrote:
>
>
> 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.
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