<table border="1" cellspacing="0" cellpadding="8">
    <tr>
        <th>Issue</th>
        <td>
            <a href=https://github.com/llvm/llvm-project/issues/61941>61941</a>
        </td>
    </tr>

    <tr>
        <th>Summary</th>
        <td>
            [AArch64] Dllimport ignored on function calls in some contexts with globalisel
        </td>
    </tr>

    <tr>
      <th>Labels</th>
      <td>
            backend:AArch64,
            globalisel,
            platform:windows
      </td>
    </tr>

    <tr>
      <th>Assignees</th>
      <td>
      </td>
    </tr>

    <tr>
      <th>Reporter</th>
      <td>
          mstorsjo
      </td>
    </tr>
</table>

<pre>
    It looks like aarch64 code generation ignores/loses the dllimport aspect of function calls in some contexts. CC @efriedma-quic 

```c++
extern "C" __declspec(dllimport) void myFunc(void);

void call(void) {
 try { 
    myFunc();
  } catch (int) {
  } 
}
```

```
$ clang -target aarch64-windows-gnu dllimp.cpp -S -o - | grep myFunc
        bl      myFunc
```
Even if `myFunc` is declared `dllimport`, it gets referenced as a direct function call to the symbol `myFunc`, instead of indirect via `__imp_myFunc`. This seems to be an issue with globalisel which gets used by default in `-O0` mode; if adding `-O2` or `-mllvm -fast-isel`, it generates the expected pattern:
```
$ clang -target aarch64-windows-gnu dllimp.cpp -mllvm -fast-isel -S -o - | grep myFunc
        adrp    x8, __imp_myFunc 
        ldr     x8, [x8, :lo12:__imp_myFunc]
```
The `try`/`catch` structure is essential here - for a plain function call without being wrapped in that, it ends up generating the right call too. If compiled targeting `aarch64-windows-msvc`, it also generates the correct reference to `__imp_myFunc`.

It seems like global isel bails out in all the cases where it generates the correct reference to `__imp_myFunc`; if adding `-mllvm -global-isel-abort=1`, it errors out with `fatal error: error in backend: unable to translate instruction: call (in function: _Z4callv)` (targeting `aarch64-windows-gnu`, without the `try`/`catch`) or `fatal error: error in backend: unable to translate instruction: invoke (in function: ?call@@YAXXZ)` (targeting `aarch64-windows-msvc`); this indicates that the code generation skips using global isel on these functions normally.

So with that context, it seems like the logic that chooses to bail out on dllimport function calls fails to recognize it and proceeds with global isel, in the case of `aarch64-windows-gnu` wrapped in `try`/`catch`.
</pre>
<img width="1px" height="1px" alt="" src="http://email.email.llvm.org/o/eJysVjtz2zgQ_jVQs0MNBUq0VKiQrdNMqiuSIpfGAwJLEjEI8ABQtu7X3yxI6xXnLkU8GlPErrCP79uHCEE3FnHLVo9stZ-JIbbOb7sQnQ_f3axy6rT9FME49xLA6BcEIbxsyyVIpxAatOhF1M6CbqzzGBg_GBcwQGwRlDG6652PIEKPMoKroR6sTD-QwpgA2kJwHYJ0NuJbDHN4egK2zLH2GlUnsr8HLYHle5bvpv9lPn4k44_0Saf4FtFbYJw_Mc7h-VmhNGSU8fXZDcY3cHRaQXc6DJZE9Mb4hhWP1yaSDvl30QD2MKlA9Cd6m5wCgMt111cBsIc9SBFlC4yvtY231yTxZPVhfxfbhwFPr3wJ0gjbQBaFbzC-Q5K9aqvca8gaO0ypn8u-h-wzZA4yYA9P0Hjs3909u09_lRmf17I7w38c0YKugZX5pFXmoANQpoVHRYJLqsuc8SfQERqMATzW6NFKVCACCFDaEx9uyADRJdaEU1c5c2MmXWVDRKGIQ9pOvz9qQXrPz7rrn8_ac_jS6gABsQt0aYUgLOgQBoRXHVtojKuE0QENvLZatqOPQ0AF1QkU1mIwkajJyjz7kzIAnVPIikeKXyilbTPKOMmcTy-dMccOslqEmNHd1ylIZTJVBb5RLaCCXkQiLSt-F9D3Hvwa9EL5np5va3L3Opdwq2iUh4siWz1OX4qdcQvOit0NDquPOf2lRcpW9KeUnwMVMtUIJTJEP8g4eCRaYQhooxYGWvQIGdTOg4DeCG3viEOguiFChQTMqxd9j4rwi62IEwZoVYChP7cs2yQwvG7a-E4_N4dPNUjX9dqggjHrE9b3ue_CUV4QFia4O5il84mjZ-oTFT8g63Wpf4oTa1OrHWkKCclKaBOAgtQWkrdkQlCnfU35-YFmv2j_R1JPLBqtJx5loqKSLvaLS8TovfOjR6mmWJnXIgozClixG7-Qu5WQL2gVnQ1WVCZ5Er2wwYiIqbAJd-2oFEYsUsM8o0zHz9-WJDlSiy1zUvhPeBo7TL6-kyP-nHjUmMci_j0haHt0L_hBEKw4pLGyzNky_2v39eu3XwznzDaaLxCpvVETlBPaIk6Q387k8KJ76mt06TWZHFUGBjz7FsA63wljTjd0_OxGbJOBaUJP8F_RlCwb12g56bVuXABcIm1iiLNXu8DdBlAnZkcHHqVrrP4ncVlYBb13ElGF66adAhjHwbkEaCT8lALX7eAn8M9naluoTbERM9wuynVePjzwRTFrt8Vy-bCuxGJdqQ3neYHrGkVdblaLBVb1qprpLc95kS_zVV4uy1Uxx1qptVys8_Wyqqt1SatMJ7SZU1HNnW9maQ5ty8VmuZgZUaEJafvi_MKx3S5FwjhnaZ25zKvzUW9ErJ3vWLGb4iXRaj_zW7KUVUMT2DI3OsRwsR11NGnZe7ew2sP-DMy4wilC63-2tPsxOhu82bYx9oGGGT8wfmh0bIdqLl1HK6E5vj-y3rvvKCPjh5QJ2hhTMv4NAAD__00ZZc0">