[llvm] [lit] Add target-x86* features

[mgorny]

Summary

Add a 'target-x86' and 'target-x86_64' feature sthat indicates that
the default target is 32-bit or 64-bit x86, appropriately. Combined
with 'native' feature, we're going to use this to control x86-specific
LLDB native process tests.

[labath]

When I requested this, I expected you would go and add something to the lldb lit config files. However, the way you've chosen to implement that seems to complement nicely the existing features in the llvm files, so I think it may go in here as well. But, I'd like for someone from the llvm side to sign off on this as well.

The one question I have is whether we really want to bundle x86 and x86_64 into one feature. It seems to me that if you were to extend the motivating test only slightly (e.g. to include %xmm8-15), then you'd need to differentiate between the 32 and 64 bit variants. OTOH, if these are separate features, then you can always say REQUIRES: x86 || x86_64 for tests that work on both.

[phosek]

LGTM

[phosek]

In D60474#1460785, @labath wrote:

When I requested this, I expected you would go and add something to the lldb lit config files. However, the way you've chosen to implement that seems to complement nicely the existing features in the llvm files, so I think it may go in here as well. But, I'd like for someone from the llvm side to sign off on this as well.

The one question I have is whether we really want to bundle x86 and x86_64 into one feature. It seems to me that if you were to extend the motivating test only slightly (e.g. to include %xmm8-15), then you'd need to differentiate between the 32 and 64 bit variants. OTOH, if these are separate features, then you can always say REQUIRES: x86 || x86_64 for tests that work on both.

Looks like we raced with @labath, I agree with his response that you can also use REQUIRES: x86 || x86_64 to achieve the same, so the question is how many of these cases you're going to have in lldb, if it's just handful then it's probably not worth introducing a new feature, but if it's going to be a significant number then a new feature is reasonable.

[craig.topper]

llvm/utils/lit/lit/llvm/config.py

100

Don't 32-bit x86 triples use i386 or i686 rather than "x86"?

[mgorny]

llvm/utils/lit/lit/llvm/config.py

100

Yes, you are correct. I don't know what I was thinking yesterday but I'll also split it into x86/x86_64 as well whle at it..

llvm/utils/lit/lit/llvm/config.py

def __init__(self, lit_config, config):
                 host_cxx = getattr(config, 'host_cxx', None)
                 if 'address' in sanitizers and self.get_clang_has_lsan(host_cxx, target_triple):
                     self.with_environment(
                         'ASAN_OPTIONS', 'detect_leaks=1', append_path=True)
             if re.match(r'^x86_64.*-linux', target_triple):
                 features.add('x86_64-linux')
             if re.match(r'.*-windows-msvc$', target_triple):
                 features.add('target-windows')
+            if re.match(r'^i.86.*', target_triple):
+                features.add('target-x86')
+            elif re.match(r'^x86_64.*', target_triple):
+                features.add('target-x86_64')
 
         use_gmalloc = lit_config.params.get('use_gmalloc', None)
         if lit.util.pythonize_bool(use_gmalloc):
             # Allow use of an explicit path for gmalloc library.
             # Will default to '/usr/lib/libgmalloc.dylib' if not set.
             gmalloc_path_str = lit_config.params.get('gmalloc_path',
                                                      '/usr/lib/libgmalloc.dylib')
             if gmalloc_path_str is not None: