IR tests fail on Windows for target x86

[rainers]

The IR tests always fail for me on Windows testing the x64 x86 build.

With the generated VS projects, it seems the ldc2 executable is expected in the build-ldc2-x64/bin folder, but it is generated to the Debug/Release subfolder:

Command 0 Stderr:
'C:/s/d/ldc/build-ldc2-x64/bin/ldc2': command not found

With the Ninja build, ldc2 is found, but the test fails with this snippet found in the LastTest.log file:

Command 1 Stderr:
C:\s\d\ldc\ldc\tests\ir\attributes.d:12:15: error: expected string not found in input
// CHECK-DAG: define void @{{.*}}sectionedfoo{{.*}} section "funcSection"
              ^
<stdin>:1:1: note: scanning from here
; ModuleID = 'C:\s\d\ldc\ldc\tests\ir\attributes.d'
^
<stdin>:19:37: note: possible intended match here
define x86_stdcallcc void @"\01__D10attributes12sectionedfooFZv"() #0 section "funcSection" {
                                    ^

It seems the additional calling convention is unexpected.

Here's the output for align.d:

Command 1 Stderr:
C:\s\d\ldc\ldc\tests\ir\align.d:12:11: error: expected string not found in input
// CHECK: define void @_D5align23passAndReturnOuterByValFS5align5OuterZS5align5Outer
          ^
<stdin>:35:80: note: scanning from here
@_D5align5Inner6__initZ = constant %align.Inner_init zeroinitializer, align 32 ; [#uses = 0]
                                                                               ^
<stdin>:46:20: note: possible intended match here
define x86_stdcallcc void @"\01__D5align23passAndReturnOuterByValFS5align5OuterZS5align5Outer"(%align.Outer* inreg noalias %.sret_arg, %align.Outer* byval %arg_arg) {

The other 3 tests are reported to pass.

[kinke]

AppVeyor doesn't have that issue, nor did I (last run probably a month ago or so). I'm pretty sure I've never seen the x86_stdcallcc calling convention in IR for Win64, especially not for align.d. The Win64TargetABI doesn't overwrite the default TargetABI::callingConv() method returning llvm::CallingConv::C. So I suspect that you're targeting 32-bit Windows, Rainer.

[JohanEngelen]

I was worried about this. In LLVM/clang, many tests explicitly specify a target triple on the cmdline. Perhaps we should do the same for (some of) our tests. For example for the align.d test, I guess we are content if it passes for one triple (provided that that triple is supported on all platforms).
It is possible to annotate that a certain test is expected to fail for certain configurations, or that a certain config is required for the test to run (see e.g. attr_target_x86.d). We could also use that to disable/enable tests selectively.

For the ldc2 search path, I only build with ninja and did not test other build systems. In tests/ir/lit.site.cfg.in (Python code) you can see that it uses CMake's LDC2_BIN variable for ldc2. It is the same as is used to build Phobos/druntime I think? In the CMake output folder, you should find tests/ir/lit.sit.cfg with @LDC2_BIN@ replaced with the path to ldc2. If that is not correct, then somehow the CMake variable is not set correctly.

[JohanEngelen]

Allowing additional calling conventions is easy: can you try changing the FileCheck line to:
// CHECK: define{{.*}} void @_D5align23passAndReturnOuterByValFS5align5OuterZS5align5Outer
In-between double parenthesis {{ ..... }} is interpreted as a regular expression.

[kinke]

I was worried about this. In LLVM/clang, many tests explicitly specify a target triple on the cmdline.

In align.d, I explicitly did not want to specify a specific triple, as it should pass for every supported platform. There are just some hacks (read: disabled checks) wrt. MSVC, for which we currently disable some alignments (e.g., sret params). So disabling some checks for certain triples would be cool. I haven't digged into that though.

[JohanEngelen]

So disabling some checks for certain triples would be cool. I haven't digged into that though.
I think it is only possible to disable/enable tests per file. So I guess you'd have to make a second align2.d test file with the tests that fail on MSVC.
I agree that explicitly specifying a platform is not so good.
To define new "features" (things you can disable/enable tests with using XFAIL and REQUIRES), have a look at lit.site.cfg.in, config.available_features.add. Lit is under-documented, I got this from looking at Lit source and Clang tests.

[rainers]

I can make attributes.d pass by adding "{{.*}}", but for align.d it's pretty bad because the symbol is different (\001 prefix) and the "align 32" checked later does not exist.

I'm testing 64-bit here, the header of the IR file looks like this:

; ModuleID = 'C:\s\d\ldc\ldc\tests\ir\align.d'
target datalayout = "e-m:x-p:32:32-i64:64-f80:32-n8:16:32-a:0:32-S32"
target triple = "i686-pc-windows-msvc"

but I'm using the release_38 branch of LLVM. The ldc branch contains my x86 patches, but I'm pretty confident it does not change x64 builds.

[rainers]

target datalayout = "e-m:x-p:32:32-i64:64-f80:32-n8:16:32-a:0:32-S32"
target triple = "i686-pc-windows-msvc"

On second look, this seems to be x86. It uses the default of ldc2 from the ninja build. I expected this to build 64-bit code. I'll change the title...

[kinke]

A small fix/adaptation wrt. explicit calling convention/special name mangling is in the works. What's left is fixing #1356 for MSVC targets, which will then allow to re-enable the currently disabled sret alignment checks in align.d and fix the byval alignment checks which will still fail for 32-bit MSVC for the time being. Therefore I'm closing this.

[JohanEngelen]

Nice