Add "verify-machineinstrs" flag to callbr tests. Relax some of the verification
tests to account for callbrs.

In D70929#1766125, @vsk wrote:

Could you add a test?

Use range-based for loop.

Add testcase for callbrs with different output constraints jumping to the same
default location.

Any further comments?

Ping? :-)

Adjust loop.

Don't add to BasicBlock, but just loop directly.

Changes made. PTAL

Remove a "const_cast" and use iterators for output constraints.

Friendly ping. :-)

Friendly ping. :-)

Move adjustment before error check.

Adjust label references to account for in/out constraints.

Simplify check that a basic block is the target of an indirect jump from callbr
and add testcase for this.

Temporary change to determine if a block is used in a callbr.

Don't split critical edges into a callbr indirect destination.

Add blurb about asm goto with output constraints to the "language extensions"
documentation.

the real update this time.

In D69876#1741381, @nickdesaulniers wrote:

Nice catch! I updated the patch with a fix. PTAL.

Please add a test for that!

Analyze "asm goto" for initialized variables.

In D69876#1740286, @jyknight wrote:

I think -Wuninitialized (UninitializedValues.cpp) should be taught how to detect the use of output variables in error blocks, at least for trivial cases.

Actually, for some reason -- it looks like the warning is failing the wrong way right now, and emits an uninitialized use warning even where there shouldn't be one.

Nice catch! I updated the patch with a fix. PTAL.

In D69876#1740289, @jyknight wrote:

Also, since this means we are no longer simply implementing according to GCC's documentation, I think this means we'll need a brand new section in the Clang docs for its inline-asm support.

This change is ready for review. PTAL.

This change is now ready for review. PTAL.

Add testcase for multiple output constraints.

Adjust the ASM so that it references labels.

Emit asm goto fallthrough early so that any value extracts will show up in the
fallthrough block and not directly after the callbr.

Update description to use "fallthrough" and "indirect"

Update language reference.

In D68483#1697207, @thakis wrote:

I reverted this in r373898 since MC/AsmParser/directive_ascii.s failed on bots. I didn't look into it, but maybe it's because there's no bounds checking on the i + 1 index.

Adding testcase for hex over 0xFF.

You forgot to add the InfiniteLoopCheck.cpp file.

LGTMing. Others please comment if you have objections.

The llvm/test/CodeGen/AArch64/callbr-asm-obj-file.ll change LGTM.

This PR is possibly related to the original issue: https://bugs.llvm.org/show_bug.cgi?id=42956

Move method out-of-line to keep MCContext.h simpler.

In D65352#1622024, @nickdesaulniers wrote:

I think the comment in LLVMTargetMachine::addAsmPrinter about // Don't waste memory on names of temp labels. should be amended in this patch to say ... unless it's address is taken or something to that effect.

Update testcase.

Remove smelly code and use correct triple in test.

In the "Revision Contents" box, there's a "Stack" tab. It looks like that's what shows the relationship.

It's not enough to just check that a BB's address is used by a callbr, since
the value doesn't have to be directly used by it. E.g., it could be stored into
memory and then loaded.

Remove accidentally added files.

Ah! Good point. Use "any_of" instead of creating a symbol for all block addresses.

Ugh! The last update combined D65304 with this...:-/

In D60943#1619579, @JamesNagurne wrote:

In case you haven't seen, this commit breaks non-x86 build bots due to the combination of '-triple x86_64*' and '-S'. Some tests that use this target are only looking for AST dumps, and do not actually require such a target. This is not one of those tests, as it's inspecting assembly.
See clang/test/CodeGen/addrsig.c to see how that is handled (via REQUIRES: x86-registered-target).

Oddly enough, other tests that use -triple x86_64* and only inspect the AST don't require the registered target.

Friendly ping. :-)

Friendly ping. :-)