The problem is that ArmInstrInfo.td defines STRD as requiring HasV5T whereas it should require HasV5TE. LDRD has the same bug.

Research:

• http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0135a/ch01s02s01.html

"ARM1020T is built around the ARM10TDMI processor unit. This is an ARMv5T implementation ..."

• http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dvi0014a/ar01s04.html

ARMv5T has no STRD -- it only has STR, STRH, and STRB. Same for LDRD.

• http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/18564.html

"Architecture v5TE and later processors provide LDRD and STRD instructions to load/store 64-bit data, ..."

Changing as I described above makes the test case not output STRD, but only if I also remove the line

target triple = "armv5-unknown-linux-gnueabi"

from the .ll file and recompile. Leaving it there overrides my command-line -mcpu flag and still generates STRD instructions while also printing out the line

.cpu arm10tdmi

which is contradictory.

So, while we should just fix the STRD and LDRD definitions, there's another bug here.

STRD and LDRD instruction definitions fixed in r80244, the other issue still remains.

ARMPreAllocLoadStoreOpt::CanFormLdStDWord() should return false for pre-ARM v5TE architectures

I believe I've just bumped in the remainder of this bug, i.e. ldrd/strd instructions were still generated despite having selected a pre-ARM v5TE architecture. I've created a simple patch for ARMPreAllocLoadStoreOpt::CanFormLdStDWord() which fixes my problem.

Thanks. I've applied the patch.
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20090928/088107.html