Moving to llvm-dev...
Hi Andy,
I have been able track down the reason for the difference in output
generated by
opt. The difference is caused when the target triple specified in the
test-case
is not a supported target for opt/clang/llvm. In this case, opt doesn't thow
an
error and hence, later in LSR the NoTTI::isLegalAddressingMode is called
which
results in the different output.The clang-native-arm build-bot builds clang with ARM being the only
supported
target[1]. This is the reason the failure occured only on this build-bot.
The
problem can be reproduced on x86-hosted clang, if you only build it with
only
ARM as the supported target.I think this problem is responsible for other failures on non-x86
build-bots.There a few possible solutions to this problem, but I am not sure which one
is
the right solution:(a) Error out if *explicitly* specified target-triple is not supported.
However, this may cause a number of tests to fail on non-X86 hosted
build-bots as:
Tests (with explicit target-triple): 1050
Tests (i686,x86) : 738
Tests (arm/thumb) : 132
Tests (powerpc) : 128
Tests (mips) : 11(b) Skip tests if *explicitly* specified target-triple is not supported.
However, this will result in a number of test being skipped on non-x86
build-bots.(c) Modify the tests to cope with the case when the specified target is not
available.Let me know what do you think? I would be glad to be involved in defining a
proper
solution in this case. I am happy to open a PR if you think is the best way
to
resolve this issue.Regards,
Manish[1] Configure command:
/home/buildslave/slave_as-bldslv1/clang-native-arm-cortex-a9/llvm/configure
--disable-bindings --build=armv7l-unknown-linux-gnueabihf
--host=armv7l-unknown-linux-gnueabihf
--target=armv7l-unknown-linux-gnueabihf --with-cpu=cortex-a9 --with-fpu=neon
--with-float=hard --enable-targets=arm --without-llvmgcc --without-llvmgxx
--prefix=/home/buildslave/slave_as-bldslv1/clang-native-arm-cortex-a9/None
--enable-optimized --enable-assertions
Thanks for figuring this out Manish.
It seems to me if you don't bother to build a target, it's fair that you won't benefit from tests designed for that target. When I care about testing a change, I build *all* targets. Conversely if you want a test to be platform independent you shouldn't specify a triple.
However, this may be a naive perspective considering the high percentage of tests with triples living in platform-independent test directories.
I'm moving the thread to llvm-dev because I'm sure someone else has thought about this problem. Hopefully they can tell us what to do...
It wouldn't hurt to open a PR to capture the discussion and decision.
-Andy