[LLVMdev] Newbee question: LLVM backend regression tests for thumb1 targets on simulator possible?

[Kristof Beyls]

> > $ qemu-arm -cpu ?
> > Available CPUs:
> >    arm926  arm946 arm1026  arm1136  arm1136-r2 arm1176  arm11mpcore
> > cortex-m3
> > cortex-a8
> >    cortex-a8-r2 cortex-a9 cortex-a15 ti925t pxa250 sa1100 sa1110
> pxa255 pxa260
> >    pxa261 pxa262 pxa270 pxa270-a0 pxa270-a1 pxa270-b0 pxa270-b1 xa270-
> c0
> >    pxa270-c5 any
> >
> > Still your procedure will work, just by using the m3 instead :-).
> Yeah, that should work for the most part, unless you emit thumb2
> instructions (which will work on cortex-m3, but not m0). The list of
> them is pretty small though IIRC, so maybe you can write a script that
> disassembles & checks for them.

Cortex-M0 implements the v6m architecture.
Cortex-M3 implements the v7m architecture.

Having had a quick look at the v6m and the v7m ARMARM's, next to the
extra instructions v7m supports, I think the main other difference
that's very relevant for a code generator is that v6m always generates
a fault when an unaligned access occurs, whereas v7m can support unaligned
accesses for many of the load and store instructions. I think it'd
be important to set the CCR register on the v7m simulation so that
it always generates an alignment fault in case there's an unaligned
access, i.e. setting CCR.UNALIGN_TRP to 1.

To check that clang indeed only produces v6m instructions when
telling it to target Cortex-m0, I think we could rely on LLVM's
MC layer correctly modelling if an instruction is part of v6m or not,
as our internal MC Hammer test suite[1] has finally, since about 1
month ago, started passing completely for the v6m architecture.
Potentially, just making sure that a build with assertions enabled
would result in an assertion failure being triggered when a non-v6m
instruction gets emitted could be good enough, as a starting point?

Thanks,

Kristof

[1] http://llvm.org/devmtg/2012-04-12/Slides/Richard_Barton.pdf