@Mordante Please check patch D146379. Some test cases fail, but I tried to explain this UB.

If you are not so sure, you are free to revert my commit. ^_^

Would it be possible to fix this issue quickly, if not can you revert this patch?

ping?

Add comments

In D145293#4176933, @pcc wrote:

To be honest, I would rather we look at removing OptimizeGlobalAliases altogether. As I explained in D65118, these kinds of trivial alias "optimizations" on their own can be more harmful than helpful.

In D145293#4176631, @MaskRay wrote:

How does rustc use llvm.compiler.used or llvm.uses?

Fix test.

In D144563#4152211, @xbolva00 wrote:

Precommit tests?

Otherwise looks good.

Fixed typo

Thank you very much for your review!

Add some tests with inbounds + null_pointer_is_valid.

Simplify the branch logic

Add NullPointerIsDefined check and fn_noundef_arg case

Sad, it still looks like it failed.

Another thing I'm curious about is why all the gep zero have been removed in the llvm/test/Transforms/SimplifyCFG/UnreachableEliminate.ll file at the 8979ae42769e529b0f6fce3268492ffb49bd54b9.

According to https://github.com/google/sanitizers/wiki/SanitizerBotReproduceBuild, I can reproduce the issue locally. But this build is taking too long, and I'm still verifying the sanitizer checks after the fix.

check !PtrValueMayBeModified.

Thank you for your review and answer. I have commit access. After https://reviews.llvm.org/B214570 succeeds, I will rebase the commit and run ninja check-all once locally to confirm it is correct.

Add the use case with only nonnull.

Fix typo.

Add nonnull and noundef.

Fix test cases

Fix the undefined ptr case

add *Impl

Thank you very much for your help!

Use auto

Mark something as completed.

Remove ContextCU as an argument

Add more detailed description for test

In D136039#3861089, @dblaikie wrote:

If we wanted to fix this whole class of errors, maybe it's time we moved most of the DIE creation operations back to DwarfDebug - and any unit-specific operations would then have to explicitly look up the right unit from the DIE before they could be used. This would reduce the chance of accidentally using the wrong unit? (it'd cause more unit lookups - which should only be walking up the DIE chain. - if we make sure every DIE is added to its parent early enough, which seems plausible)

Update code

In D135267#3853081, @aprantl wrote:

In D135267#3849760, @dblaikie wrote:

In D135267#3842862, @DianQK wrote:

There seems to be a lot of complexity to consider here, would adding an option to control DINode can be shareable be a good suggestion?
Pseudo-code:

bool DwarfUnit::isShareableAcrossCUs(const DINode *D) const {
  ...
  return ((isa<DIType>(D) && !option("disable-die-share-across-cus"))||
          (isa<DISubprogram>(D) && !cast<DISubprogram>(D)->isDefinition())) &&
         !DD->generateTypeUnits();
}

I'm not ready to understand what solutions might be appropriate as I'm still trying to understand the problem and why it arises for Swift but not C++ - sorry I haven't had enough time to try to get the context clearly in my head.

I don't have a Swift compiler, and don't really know Swift (so I'm not sure what Foo: Hashable means - in C++ that would be derivation, and Hashable wouldn't have any reference to Foo (only the other way around, Foo would reference Hashable) - could you include the LLVM IR for this small example so I could take a look?

struct Foo: Equatable, Hashable {}

Is a definition of a struct with the name Foo that conforms to the protocols Equatable and Hashable. Protocols in Swift are somewhat similar in spirit to Concepts in C++. Defining Foo to conform to Equatable to somewhat similar to declaring bool operator==(const Foo &) = default; in C++. Because of the protocol conformance the compiler must emit a witness table (~ vtable) defining how to call the methods required by Equatable on a Foo object.

There seems to be a lot of complexity to consider here, would adding an option to control DINode can be shareable be a good suggestion?
Pseudo-code:

bool DwarfUnit::isShareableAcrossCUs(const DINode *D) const {
  ...
  return ((isa<DIType>(D) && !option("disable-die-share-across-cus"))||
          (isa<DISubprogram>(D) && !cast<DISubprogram>(D)->isDefinition())) &&
         !DD->generateTypeUnits();
}

@dblaikie
Following your case, I created one swift example.

In D135267#3837570, @dblaikie wrote:

Sorry, I'm not really understanding most of this - could you explain further what you mean by "successor" nodes and what "order free" means in this context?

rebase the patch to make sure everything is based on an up-to-date origin/main.

Many thanks for your review @jinlin. I don’t have commit access, can you land this patch for me? Please use “DianQK dianqk@icloud.com” to commit the change.

update machine-outliner-side-effect-2.mir