r200233 - Cortex-M3 and Cortex-M4 should not enable hwdiv-arm

[Reid Kleckner]

There are a limited number of clang tests that check generated assembly in
test/CodeGen, if you want to go that path, but it needs something like "//
REQUIRES: arm-registered-target".  Testing generated assembly from clang is
generally discouraged, though, for better or worse.

You could also do a purely semantic test like (untested):

// test/Sema/arm-cortex-cpus.c
// RUN: %clang_cc1 -target arm-linux-gnueabi -mcpu=cortex-m4 -verify
// expected-no-diagnostics
#ifndef __ARM_ARCH_EXT_IDIV__
# error "hwdiv wasn't set for cortex-m4!"
#endif


On Tue, Jan 28, 2014 at 10:03 AM, Artyom Skrobov <Artyom.Skrobov at arm.com>wrote:

> Hello Reid,
>
> > A couple things wrong here:
> > 1. This test fails if ARM is not a registered target (add "// REQUIRES:
> > arm-registered-target" to fix)
> > 2. Clang tests shouldn't test generated assembly, that's what LLVM tests
> > are for
> > 3. Driver tests shouldn't do IR generation, which this test does
>
> This test is neither for the generated assembly per se, nor for the IR;
> it's for the target features, which are set in the front-end, and only
> affect the ARM build attributes that are emitted.
> The IR output doesn't include the build attributes, so it is completely
> unaffected.
>
> > I'm reverting this in r200242 for now, but feel free to recommit a test
> > in test/CodeGen that verifies you get the right attribute bits in the
> > IR, if that's how this gets passed down to LLVM.
>
> No, this doesn't affect the attribute bits in the IR; I can see that the
> list of target features is passed to clang::EmitBackendOutput, which uses
> it to create an llvm::TargetMachine, which is then used to generate the
> output.
> Therefore, the only way to test this change is via the generated machine
> code.
>
> It might be possible to hack the IR printer so that for ARM targets it
> included a comment with a dump of the target features or the build
> attributes; but given that it's only needed for this test, I'd argue this
> would be even more sloppy than checking for the build attribute in the
> generated assembly.
>
> Do you agree?
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140128/3c0795fa/attachment.html>