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

    <tr>
        <th>Summary</th>
        <td>
            [Clang/CodeGen] Ill-formed LLVM generated with -fstrict-vtable-pointers and optimization for MSVC target
        </td>
    </tr>

    <tr>
      <th>Labels</th>
      <td>
            clang:codegen,
            llvm:codegen
      </td>
    </tr>

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

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

<pre>
    This reduced test case has been causing crashes recently when assertions are enabled:
```
struct c {
  virtual ~c();
};
struct d : virtual c {};
class a : d {};
a f;
```
When compiled with recent changes in trunk, this crashes in `InstCombine` pass:

`clang -cc1 -triple x86_64-pc-windows-msvc -emit-llvm -fstrict-vtable-pointers -O1 test.cc`
```
Assertion failed: DT.dominates(BB, UserParent) && "Dominance relation broken?", file llvm\lib\Transforms\InstCombine\InstructionCombining.cpp, line 4031
```

As far as I can see, the crash is new but we have been generating ill-formed IR for a very long time.
Changing the frontend invocation so that the verifier is executed produces:

`clang -cc1 -triple x86_64-pc-windows-msvc -emit-llvm -fstrict-vtable-pointers -O1 -disable-llvm-passes test.cc`
```
Instruction does not dominate all uses!
  %1 = call ptr @llvm.launder.invariant.group.p0(ptr %this1)
  %3 = call ptr @llvm.launder.invariant.group.p0(ptr %1)
fatal error: error in backend: Broken module found, compilation aborted!
```

You can easily reproduce this as is as far back as LLVM-14, but that's because the verifier call that catches it during this invocation was introduced between 13 and 14, in this commit: https://github.com/llvm/llvm-project/commit/9efce0baee4bdda9d824716668ac3d3027bfa318

If you backport this patch, I have seen this problem in at least LLVM-11, but that's because I just stopped there, the build system was starting to get difficult.

On a related note, why aren't we just always running the verifier? It doesn't seem to cost too much.
</pre>
<img width="1px" height="1px" alt="" src="http://email.email.llvm.org/o/eJy8ls-P27YSx_8a-jKQIVG2bB982LXhBwMJ8vBemqKnYkSObGYpUiBHdpxD__aC1Hp3EyQo2kOBxVrmj_n5ma-MMZqTI9qK5aNY7mc48tmHbW--XujJX2at17ftx7OJEEiPijQwRQaFkeCMEVoiBwrHaNwJVMB4pnRUkWN7g-uZHGCMFNh4FwEDATlsLWlRP4hyL8oH0ZTPf_lr5DAqBgVi9TitAFxM4BEt_KGEXAu5EfXzlljtX56fL2oQ9cPLjcnMm1PKYoyA-ZD-fhOhezX9bVi_pkyU7wdjScPV8Pk5S1BndCeKYBxwGN2TkDvgVLB7NYwD0ZRHF3nn-9Y4Ek0JA8b4WoK7R2XRnaBQqoKCgxkswZd183uzKAZVXI3T_hqLPl4UFNQbLqy99FB0kYNRXFw4VbYYvHFMIULxocrdmiv1ksd3aT3cewMdmqkrsP841743DpmikOvHx5TRL5HCfzGQYyE3IGQjZANCyn0-6RRBIIvZUhv8EzlRH4SU6WpnLEGKVCx31rRiufsY0MXOhz6K5e5tYaZvqY_Gu2nRuNNcDUMyZI0jWJR19cNU7glBhwEwwhEUOohEU0No6geYCI6u0I4M14TwhSaGT-QoICeMjbVFio40HP8HnQ-AcKFwA-vdCdj0NJ-c7VLr041kvgveMTkNxl28mkoRPfAZOe9fKJjOUEgR0BdSI5OGIfg0Vf8KCoU2Ma-mo0UCkOJf8fGmHaA9RXCe4U4HoLUwxkRJdR9VIZcViHoPKm0OHEAsyuRwbnF0msLcuAsGg47np-DHYT6UQq7zQblMc1OlAX-1Vv9za6-WOmS0QCH4kAjPD2kuW1RP5DL1j5la6L0eLUHnR6cTONPIT93E1gcm_ZLtDwH8zY8ZPMJo7A0CPbd40gSMMP1PkCbv6fndu0_vi2qR3CUsEzFCrpK2JmGlb-nJlchQKWSV9YVBj2HC0MS3-F2TO8dTABpa4mtCvaoBnYbJY5KtrFa-7w2nSpyZhwykPAh5OBk-j-1c-V7IQ57i6aMYgv9MioU8PF-Vhw11isoWiRat1rjRa7lYVU3TrFHVui7lqu2wrtZv63Xs4ObHXIvBB56CGVJqKbrjNKExhT3tBN9a6lPYyGAJIz_Xr_pp_Y7weYwMkf0wpBfYmcKLKLSjsRriLTL1uV6RMWQVYA8nYtCm64waLc_fRv3BAU6KRzrNRLZ3Pd_SG84Jucrikr2iveItQhiduyvFvZeiPsCR81xNdyJRn_wqHxnYe-hHdZ7P9LbWm3qDM9pWzaaRZdUs1rPzlnCjaaHVWhM29aIpa13VdbdupV5gVVczs5WlrKuyrGRdruR6XjfVql7ruluQ6tbtUixK6tHYeZ4pH04zE-NI22a1qVcziy3ZmH8ZSJn1SNQPyms6pRyTtgspMxLfLC_3s7DNiLTjKaaBNZHjqws2bPPvjV02KQ87r-k_5MRyD8dX6U1dvavy_ZX7U31LPPuBTW--Tugn1X7__087YAwn4tkY7PZvg52LEYU85Hr8GQAA__-EdPhl">