[llvm] [Windows][test] Fix "LLVM" test failures when LLVM_WINDOWS_PREFER_FORWARD_SLASH is ON (PR #184556)

[James Henderson via llvm-commits]

================
@@ -7,5 +7,5 @@
 ; RUN: sed -e "s,SRC_COMPDIR,/Inputs,g" %p/Inputs/source-interleave.ll > %t.ll
 ; RUN: llc -o %t.o -filetype=obj -mtriple=x86_64-pc-linux %t.ll
 ; RUN: llvm-objdump --prefix 'myprefix/\' --source %t.o 2>&1 | FileCheck %s -DFILE=%t.o -DPREFIX='myprefix'
-; CHECK: warning: '[[FILE]]': failed to find source [[PREFIX]]/Inputs\source-interleave-x86_64.c
+; CHECK: warning: '[[FILE]]': failed to find source [[PREFIX]]{{[/\\]}}Inputs{{[/\\]}}source-interleave-x86_64.c
----------------
jh7370 wrote:

TL;DR - This should be [[PREFIX]]/Inputs[[SEP]]source-interleave-x86_64.c (with `SEP` defined as `%{fs-sep}` as in other cases). It might be worth a comment summarising why, though arguably there is a chance the behaviour could change.

Detailed explanation:

I dug into this to try to understand the existing behaviour that contains a mixture of slashes.

If you take a look at the behaviour of the original test and the code, it sort of makes sense that there are a mixture of slash directions in "native" slash mode. There are two aspects to consider:
1. The `--prefix` option, which adds the specified string, less any trailing slashes, i.e. `myprefix` (and not `myprefix/` or `myprefix\`).
2. The test file path is taken from the `DIFile` directive in the .ll file that is built using `llc` above. The directive consists of the "directory" and "filename". The former is set via the `sed` command before `llc` is run, then (I'm assuming - I haven't dug into the relevant LLVM source for this) `llc` uses `sys::path::append` to add the filename, which will use the preferred path separator to join them together. The result of this on Windows is `/Inputs\source-interleave-x86_64.c` when `LLVM_WINDOWS_PREFER_FORWARD_SLASH` is `ON` (note the mixed slashes), but when it is `OFF`, I'm assuming it will be `/Inputs/source-interleave-x86_64.c`.
3. The source printing uses the file path name as stated in the debug data. When `--prefix` is specified and the file path is absolute, it uses `sys::path::append` to add the file path to the prefix. A file path is considered absolute in this case if the string starts with a path separator. Currently, `sys::path::append` does a straight up concatenation if the file path starts with a slash, without any reference to the preferred path separator. This therefore results in `myprefix/Inputs\source-interleave-x86_64.c` or `myprefix/Inputs/source-interleave-x86_64.c`. Note that there is a FIXME against `sys::path::append` noting that this differs to C++17's equivalent functionality, so the behaviour might change some day, but in that case, this test would want to catch that change and things be fixed accordingly.

Although the behaviour that changes for `LLVM_WINDOWS_PREFER_FORWARD_SLASH` is actually the llc behaviour, I think there is benefit to show that the slash before `Inputs` is left as-is, regardless of the config setting. In other words, the slash after the prefix in the check should be fixed to `/` and the one after `Inputs` should be dependent on the value of `LLVM_WINDOWS_PREFER_FORWARD_SLASH`.

https://github.com/llvm/llvm-project/pull/184556