[lld/mac] Give several LTO tests an "lto-" prefix

[int3]

I intentionally omitted the lto- prefix from this (and several other tests) because it seemed redundant -- practically all our .ll tests are LTO tests. I guess that's not strictly true any more though given things like lc-linker-option.ll. There are also some LTO tests that do have the lto- prefix, so we're not consistent about it either. I guess it doesn't really matter which scheme we pick as long as we're consistent. So... if we are going to add said prefix, can we do it for all the other LTO tests as well?

[thakis]

In D105476#2859937, @int3 wrote:

I intentionally omitted the lto- prefix from this (and several other tests) because it seemed redundant -- practically all our .ll tests are LTO tests. I guess that's not strictly true any more though given things like lc-linker-option.ll. There are also some LTO tests that do have the lto- prefix, so we're not consistent about it either. I guess it doesn't really matter which scheme we pick as long as we're consistent. So... if we are going to add said prefix, can we do it for all the other LTO tests as well?

I had tried that, but apparently did a very poor job. I had looked at rg llvm-as lld/test/MachO, rg save-temps lld/test/MachO but apparently not very closedly.

Now that I look through lld/test/MachO/*.ll I found several else. I did _not_ rename these files since they don't seem primarily LTO tests:

• lld/test/MachO/bitcode-bundle.ll
• lld/test/MachO/bitcode-nodatalayout.ll (…should this one be in invalid/?)
• lld/test/MachO/force-load-swift-libs.ll
• lld/test/MachO/lc-linker-option.ll

[int3]

lld/test/MachO/bitcode-nodatalayout.ll (…should this one be in invalid/?)

yeah, putting it under invalid/ would probably make more sense. I think it should be considered an lto- test too, since the error does come from the LTO compilation. LLD-ELF does put it under test/ELF/lto/.

Thanks for the cleanup!