It will require changing all possible initializations, with a sensible value.

Added ASCII output mode. It turns out that the unicode line drawing characters do work correctly on windows (at least windows 10, I don't have easy access to anything older to test with), I've left unicode as the default.

Why are you doing this in CodeGen, rather than adjusting the existing layout code in CGRecordLowering? Doing it this way will result in AdjustAAPCSBitfieldLValue being called for every access to the bitfield, rather than just once. This is probably more fragile too, because it's spreading the logic across multiple parts of the codebase, and has to undo some of the layout done by CGRecordLowering.

LGTM

LGTM

LGTM

Thanks, our libc++ bots are passing now too: http://lab.llvm.org:8011/builders/libcxx-libcxxabi-libunwind-aarch64-linux/builds/2636

"The names are case insensitive for most targets, and usually written in lower case."

There are also some test failures (link errors caused by undefined references) on the ARM/AArch64 bots caused by this, so I'm going to revert it.

LGTM

LGTM

LGTM

How does this interact with the AArch64 "branch-target-enforcement" attribute? For the generated, unpatched code to be correct the function needs to start with a BTI or PAC instruction if it could be indirectly called. Presumably the code doing the patching would also need to be aware of this.

LGTM

LGTM

• Remove D70756 from patch
• Use -- style options in test comments

Sorry about that, I'd been marking comments as "done" as I went, but forgot to actually click "submit". I also accidentally included D70756 in the patch.

LGTM, thanks.

• Made suggested changes to tests. I've enabled strict whitespace checking just for the one test in which we check compatibility with other options which affect the layout of the output, because the disassembly uses tabs in a way which doesn't always display well in text editors.
• getLocations now works correctly with -ffunction-sections, so removed the workaround
• Removed unused parameters related to DW_AT_frame_base
• Get endianness form the DWARFunit, no need to pass it around separately
• Don't create/destroy formatted_raw_ostream as often

Made the suggested changes in the code. However, after rebasing the DWARF5 tests are failing, as the location lists are being parsed incorrectly. I'll update the tests once I've figured out that's changed there.

LGTM

• Use a switch statement in PrettyPrintDWARFOps

Remove most DWARF opcodes except for simple registers, I'll add the rest back in later patches.

This looks like multiple bug-fixes in one patch, could they be split up?

LGTM

Is there a particular reason you've used ARM rather than x86 for these tests? A loose convention from my experience is that tests that require a target, but where the target doesn't actually matter, are written for X86.

Now ready for review:

• Added tests, including a more complex expression emitted by GCC, and high register numbers needed for PPC.
• Print parentheses when needed by complex expressions, matching C operator precedence.
• Add command-line option to docs.
• Work correctly with -S and -l options (interleaved source code and line numbers), remove extra line number printing I added before I realised those options exist.

LGTM

Not ready for review yet, but added DW_OP_regx and DW_OP_bregx needed for PPC.

Ping

LGTM

LGTM

LGTM, thanks

Committed https://reviews.llvm.org/rG73c3137a82c96789f4a2b8ec9427d23fa73498d8

LGTM, thanks

LGTM with a few nits.

I've reverted this (rGa3f474542) because it is causing failures when an instruction which modifies SP gets outlined. here's a reproducer:

I'd like to see some more tests for this, in particular:

• Different combinations of register types being saved, e.g. only P regs without X or Z regs.
• Check that pairing of other register types still works in the presence of SVE callee-saved registers.

LGTM, thanks!

LGTM

I think this also needs a check to make sure the selected architecture supports PAC/BTI. Gcc gives an unknown target attribute or pragma error if this is used for a non-AArch64 target.

LGTM

So, if a, b and c participate in outlining, a and b have sign-return-address=all and c has sign-return-address=non-leaf, the new outlined function should behave like having sign-return-address=non-leaf? Or should we only allow outlining if the attributes match?

LGTM

For testing, we have the SPACE pseudo-instruction, which can be used to emulate very large basic blocks, maybe you could reduce your reproducer using that?

How about -f[no-]force-dwarf-frame, which I think matches the spelling and behaviour of the existing -fforce-enable-int128 and -fforce-emit-vtables options?

It looks like you're emitting PAC instructions but not AUT, so I'd expect this to fault when the outlined function returns. Or is some other code already returning using RETAA/RETAB? In which case, the test should check that.

I don't like the idea of adding a -gno-dwarf-frame option which doesn't always disable emission of .debug_frame. Since it doesn't make sense to emit other debug info without .debug_frame, maybe we should just not have a negative option?

Ping

Ping

A patch adding the same functionality was added back in May: D61719, rL360381.

Ping

LGTM

Ping

This makes the IR self-contained, which is good, but it also make the interpretation of the IR modal, which isn't great. It means that suddenly the rules of interpretation of what is valid to do or not changes according to this module flag.

LGTM

Ping