[llvm] [BOLT] Gadget scanner: improve handling of unreachable basic blocks (PR #136183)

[Anatoly Trosinenko via llvm-commits]

================
@@ -1428,6 +1428,90 @@ printed_instrs_nocfg:
         br      x0
         .size   printed_instrs_nocfg, .-printed_instrs_nocfg
 
+// Test handling of unreachable basic blocks.
+//
+// Basic blocks without any predecessors were observed in real-world optimized
+// code. At least sometimes they were actually reachable via jump table, which
+// was not detected, but the function was processed as if its CFG was
+// reconstructed successfully.
+//
+// As a more predictable model example, let's use really unreachable code
+// for testing.
+
+        .globl  bad_unreachable_call
+        .type   bad_unreachable_call, at function
+bad_unreachable_call:
+// CHECK-LABEL: GS-PAUTH: Warning: the function has unreachable basic blocks (possibly incomplete CFG) in function bad_unreachable_call, basic block {{[^,]+}}, at address
----------------
atrosinenko wrote:

Thank you for the suggestion, I rephrased the warning message in cdc20abc88f40170f78a2b048b5b5651b21967cc, though I used less concrete wording: not "more false positives" but "the analysis quality may be degraded". Even if incomplete CFG can only result in false **positives** when caused by jump table not being understood by BOLT (the only reason I observed in the wild so far), this seems to indicate the analyses in BOLT are _somewhat broken_ for the function, so I would not be sure that this cannot result in lots of false **negatives** under different conditions.

All the reports for dead code are *probably* false positives, but if the particular code is actually **seemingly** dead (maybe some precompiled snippet for JIT or something...), then nothing can be told for sure, but this is hardly an issue of the scanner :) Anyway, this does not look like a widespread issue worth implementing a workaround at first glance, but maybe scanning large code bases will prove the opposite...

Considering the functions without CFG at all, printing a warning for them sounds reasonable, but this turned out to break a lot of tests relying on `CHECK-NOT: function_name_nocfg` - added a FIXME in e14dce9a60d7583c2a147063f12b23b91d8aa9ba for now.

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