Hi, > Compile with -fdump-tree-all. You'll see dozens of dump files like > > hello.c.037t.addressables2 > hello.c.036t.dce1 > hello.c.035t.mergephi1 > hello.c.034t.copyprop1 > hello.c.033t.esra > hello.c.032t.sdse1 > hello.c.031t.addressables1 > hello.c.030t.forwprop1 > > Diff the pass before dce and the post-dce dump and you'll see what dce did. > There are several dce passes. > > Also, you can diff the final optimized code with and without dce. I did as you said, was trying to track it step by step at dce, but finally checked how optimized version look... the code: HardwareIndexBuffer::IndexType indexType = mCurrentSection->get32BitIndices()?HardwareIndexBuffer::IT_32BIT : HardwareIndexBuffer::IT_16BIT; where IndexType is: enum IndexType { IT_16BIT, IT_32BIT }; and mCurrentSection is pointer field in current object of which get32BitIndices() return m32BitIndices field, was optimized to: indexType = (IndexType) this->mCurrentSection->m32BitIndices; in above version the version without DCE had this in form of: if (this->mCurrentSection->m32BitIndices) { indexType = 1; } else { indexType = 0; } or exactly: D.288376 = this->mCurrentSection->m32BitIndices; if (D.288376) goto <bb 29>; else goto <bb 30>; <bb 29>: indexType.4866 = 1; indexType = 1; goto <bb 31>; <bb 30>: indexType.4867 = 0; indexType = 0; I have not much experience, but it seems like it's not that bad... maybe I should check how m32BitIndicies is initialized? (as reminder - in optimized version indexType end to be 104 by some reason...) cheers, Andrzej.