llvm-svn: 184206

llvm-svn: 184204

llvm-svn: 184203

llvm-svn: 184202

llvm-svn: 184201

llvm-svn: 184200

llvm-svn: 184198

llvm-svn: 184196

llvm-svn: 184193

llvm-svn: 184191

This allows the compiler to see the enum and warn about it. While in here,
fix a switch to not use a default and fix style violations.

llvm-svn: 184186

When using a positive offset, literal loads where encoded
as if it was negative, because:
- The sign bit was not assigned to an operand
- The addrmode_imm12 operand was not encoding the sign bit correctly

This patch also makes the assembler look at the .w/.n specifier for
loads.

llvm-svn: 184182

llvm-svn: 184181

This fixes two previous issues:
- Negative offsets were not correctly disassembled
- The decoded opcodes were not the right one

llvm-svn: 184180

llvm-svn: 184179

llvm-svn: 184178

Someone may want to do something crazy, like replace these objects if they
change or something.

No functionality change intended.

llvm-svn: 184175

llvm-svn: 184174

llvm-svn: 184173

llvm-svn: 184172

These APIs are still used, and the constant APIs are actually really important.

Removing these makes -Wdocumentation more useful.

llvm-svn: 184170

llvm-svn: 184164

llvm-svn: 184162

A bug in libObject will cause it to assert() if a symbol table's string
table and the section header string table are the same section, so we
need to ensure that we emit two different string tables (among other
things). The problematic code is the hardcoded usage of ".strtab"
(`dot_strtab_sec`) for looking up symbol names in
ELFObjectFile<ELFT>::getSymbolName.

I discussed this with Michael, and he has some local improvements to the
ELF code in libObject that, among other things, should fix our handling
of this scenario.

llvm-svn: 184161

I was spotting garbage in the output. I'd like to just zero the entire
ELFYAML::Section to be sure, but it contains non-POD types. (I'm also
trying to avoid bloating the ELFYAML::Foo classes with a bunch of
constructor code).

No test, since this is by its very nature unpredictable. I'm pretty sure
that one of the sanitizers would catch it immediately though.

llvm-svn: 184160

The error message was:

/home/espindola/llvm/llvm/tools/gold/gold-plugin.cpp: In function ‘ld_plugin_status cleanup_hook()’:
/home/espindola/llvm/llvm/tools/gold/gold-plugin.cpp:461:30: error: cannot pass objects of non-trivially-copyable type ‘std::string {aka class std::basic_string<char>}’ through ‘...’

I will check if this was a clang or gcc issue.

llvm-svn: 184138

llvm-svn: 184136

llvm-svn: 184135

llvm-svn: 184134

llvm-svn: 184133

A complex, expensive heuristic with little value in the current design.

llvm-svn: 184132

llvm-svn: 184131

llvm-svn: 184130

This eliminates the MultiPressure scheduling "reason". It was
sensitive to queue order. We don't like being sensitive to queue
order.

llvm-svn: 184129

llvm-svn: 184122

llvm-svn: 184121

llvm-svn: 184120

This ports a missing feature from PathV1.h. I am not sure how to test this
with the regular infrastructure, but an Apple bot should check this when
r183985 is reapplied.

llvm-svn: 184119

llvm-svn: 184117

Fixes rv7x0 bug in Heaven reported here:
https://bugs.freedesktop.org/show_bug.cgi?id=64257

llvm-svn: 184116