lgtm

lgtm

lgtm, thanks!

In D37740#877735, @aprantl wrote:

Seems ok to me.
@rnk: was your concern addressed?

lgtm

lgtm

• rebase

lgtm, just nits

lgtm, I actually made this change as part of llvm.dbg.addr (D37768) and then reverted it to keep the diff minimal. Thanks!

lgtm, thanks!

ping

lgtm, thanks!

Are you sure you can't reproduce this behavior by checking out the lit subtree with SVN before you deleted that directory, importing some .py files from that tree to create .pycs, and then doing svn up and checking if it creates a conflict? I'd really prefer to have an explanatory comment in here that says why we're setting this mysterious configuration.

Looks like the correct fix, thanks!

lgtm

In D31951#873893, @zturner wrote:

Please see https://bugs.llvm.org/show_bug.cgi?id=28222#c20 for a discussion of the performance implications of this patch. TL;DR - This has introduced a severe performance regression in tblgen (on the order of 4x slowdown) even for architectures such as X86 which according to the patch description should not be affected by this change.

Unless some algorithmic fix can be found relatively quickly, I'd like to open the possibility of reverting this patch until it can be re-worked to have more desirable performance characteristics, or at the very least be limited only to specific architectures.

Closing this, I now realize this was a step in the wrong direction.

Would this help with https://bugs.llvm.org/show_bug.cgi?id=32021 ?

In D37911#872701, @aprantl wrote:

Thanks! Are you running the debuginfo-tests on your changes prior to committing?

In D37929#872707, @aprantl wrote:

Do you think you could craft a debuginfo-tests test from PR34513, so we can avoid regressing in the future?

• Mostly s/MDNode/DILocalVariable/

Looks good, sounds like a plan: run lit.py like we used to if we don't have or can't find an llvm-lit.in to configure.

lgtm

This is problematic because people already complain about how compiler-rt depends on the LLVM source tree for gtest sources: https://bugs.llvm.org/show_bug.cgi?id=33693

Thanks, looks good!

lgtm

lgtm

I do remember recommending this approach over IRC, but I thought we concluded that we should leave all the defaults in lib/Basic/Targets/ and make the -cc1 -fwchar-type= and -f[no-]signed-wchar overrides that affected all targets equally. That would avoid the need for these test updates, anyway.

lgtm

In D37838#870372, @zturner wrote:

In D37838#870368, @rnk wrote:

lit.cfg.py still isn't a valid name for a python module. I had this idea that in the future we'd import the config module directly to simplify custom test formats defined in lit configuration files, which interact badly with multiprocessing.Pool. I guess that won't work well anyway since all the config files will have the same name, so we still have to move custom test formats out into well-named python modules.

Could we work around this by using __import__ or something or searching for a module loader with a given path, and just assigning a dynamically generated name to the module? Not trying to do anything like that with this patch by the way.

lit.cfg.py still isn't a valid name for a python module. I had this idea that in the future we'd import the config module directly to simplify custom test formats defined in lit configuration files, which interact badly with multiprocessing.Pool. I guess that won't work well anyway since all the config files will have the same name, so we still have to move custom test formats out into well-named python modules.

I think this looks good, even without fixing the access control crash, this seems like a diagnostic improvement.

• rebase
• implement Paul's comments

In D37715#869699, @amccarth wrote:

This sounded to me like a Python 2/3 problem, so I reset my environment to Python 2.7, re-ran CMake, and tried again. But I got the same set of Python errors. What's the trick here?

lgtm

Looks good! Make sure to run check-clang and check-llvm. The CGDebugInfo.cpp change might affect clang codegen tests that generate debug info for DWARF.

Does this look good as is? I'd like to use this to gather some user feedback.

• update

I think the main usage model this de-supports is putting tools on PATH and running lit.py directly on tests from the source directory like this:

PATH=$PATH:$build/bin llvm/utils/lit/lit.py llvm/test/Debug/X86/foo.ll

This is awesome! phab doesn't tell you the diffstat, so I patched it in, and it is: 177 insertions(+), 788 deletions(-) Nobody understood that code anyway, so this is great.

Nice! IIUC, now that the gnu ld driver works on Windows we can remove this logic. Thanks!

Nice. :)

This should have an IRGen test. You can probably extend clang/test/CodeGenCXX/debug-info-ms-abi.cpp with a static method.

+1 for dropping the old names

Looks good