Better lit.cfg "native" detection

[probinson]

Summary

The host and default target triples do not need to match for "native" backend to work.

[probinson]

I've tried this on X86 in several variations:

• default target == host triple; DebugInfo tests all work fine
• default target != host triple but X86 target included: DebugInfo tests all work fine
• ARM target only, default target triple is ARM-ish: DebugInfo tests identified as UNSUPPORTED

[mehdi_amini]

Works for me, I don't know why the original had host arch == target arch , which is why I didn't remove it.
We can try to get this in and revert if we break someone's use case.

[chapuni]

Reverted in r246352.

Paul, I am sorry if you didn't understand the comment in r193459 that I wrote.

[probinson]

I got a report that the sanitizer-windows bot failed:
http://lab.llvm.org:8011/builders/sanitizer-windows/builds/9107
which appears to be due to this patch; thanks for reverting it for me!

The test that failed is in the compiler-rt project, which I don't have checked out.
I guess the problem is a lack of clarity about what "native" target actually means.
We apparently need both kinds of predicate:
(a) host triple == target triple, or more generally: The tools we are building can be used in turn to build programs that can execute on the host; and
(b) host_arch is one of the targets_to_build, which is sufficient for things like llc tests where llc defaults to using the host triple as the target triple, but the output files do not have to execute on the host.

Looking more thoroughly into the history, it appears that "native" was intended to mean (a) from the start, so if we want something that means (b) we'll need to invent it as a new feature.

[chapuni]

Since LLVM(and clang) is "the native cross compiler", it shouldn't depend on host architecture in most cases.
I wonder there might be any cases that requires (b).

(a) also implies like "--host=x86_64-linux --target=i686-linux".
It would require remote process executing, though.

[probinson]

In D12454#235697, @chapuni wrote:

Since LLVM(and clang) is "the native cross compiler", it shouldn't depend on host architecture in most cases.
I wonder there might be any cases that requires (b).

Yes. Various tools (including llc and others) will use the host-triple as the default-target-triple, but for non-executable tests (like most of Clang/LLVM tests) it is sufficient to have the host-arch included in targets_to_build.
This is exactly the problem that I had: Mehdi added the "native" condition to DebugInfo tests, which disabled them for my cross-compiler (running on x86_64 Windows and targeting x86_64 PS4). That is not acceptable.

[mehdi_amini]

What test in LLVM is sensitive to the "native" definition a)?

[chapuni]

In D12454#235795, @joker.eph wrote:

What test in LLVM is sensitive to the "native" definition a)?

JIT tests, for now.

[mehdi_amini]

I see: lli will use the "default target triple". If you build LLVM with a default triple being ARM and you're on an X86 machine it can't run.

But what is not clear to me is that since lli was compiled using the host triple, why would it uses the default target triple? I'm not sure I see the use case here.

[mehdi_amini]

Re-reading the thread, you mentioned "--host=x86_64-linux --target=i686-linux". Is it like building lli to run in 64bits mode but having the JIT'ed code being 32 bits?

[chapuni]

JIT stuff uses host triple rather than LLVM_DEFAULT_TARGET_TRIPLE by default, for now.
(It might be improved in future)

With "host=x86_64-linux target=i686", almost all JIT tests would pass.
But I thinks they would be *false positive* since they don't check functionality of i686.

[mehdi_amini]

I'm lost and I feel you are contradicting yourself, you are saying now that the JIT tests are using the host triple, but then I don't understand why did you need to revert r246350?

[chapuni]

Excuse me to confuse you.
AFAIK, "Most of JIT tests would fail with different target triple".
I have no idea whether would be cleaner,

• Rollback using host triple into target triple in JIT, and let JIT fail with inappropriate target.
• Tweak JIT and around to run with host triple as target. I guess some part would depend on target_triple.

I'd dig around it when I have time.

test/lit.cfg

 if not 'hexagon' in config.target_triple and not re.match(r'^x86_64.*-(mingw32|windows-gnu|win32)', config.target_triple):
     config.available_features.add("object-emission")
 
 if config.have_zlib == "1":
     config.available_features.add("zlib")
 else:
     config.available_features.add("nozlib")
 
-# Native compilation: host arch == target arch and native backend built-in
-# FIXME: Consider cases that target can be executed
-# even if host_triple were different from target_triple.
-if (config.host_triple == config.target_triple and
-    config.native_target in config.targets_to_build):
+# Native compilation: host arch (native) backend built-in
+if config.native_target in config.targets_to_build:
     config.available_features.add("native")
 
 import subprocess
 
 def have_ld_plugin_support():
     if not os.path.exists(os.path.join(config.llvm_shlib_dir, 'LLVMgold.so')):
         return False