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

llvm-svn: 184115

This reverts commit r183985.

We were missing the checks for not deleting things like /dev/null.

llvm-svn: 184111

llvm-svn: 184109

llvm-svn: 184107

llvm-svn: 184106

The main advantages here are way better heuristics, taking into account not
just loop depth but also __builtin_expect and other static heuristics and will
eventually learn how to use profile info. Most of the work in this patch is
pushing the MachineBlockFrequencyInfo analysis into the right places.

This is good for a 5% speedup on zlib's deflate (x86_64), there were some very
unfortunate spilling decisions in its hottest loop in longest_match(). Other
benchmarks I tried were mostly neutral.

This changes register allocation in subtle ways, update the tests for it.
2012-02-20-MachineCPBug.ll was deleted as it's very fragile and the instruction
it looked for was gone already (but the FileCheck pattern picked up unrelated
stuff).

llvm-svn: 184105

vectorizing loops with memory accesses to non-zero address spaces. It
simply dropped the AS info. Fixes PR16306.

llvm-svn: 184103

llvm-svn: 184102

llvm-svn: 184099

This patch also adds a simpler version of sys::fs::remove and a tool_output_file
constructor for when we already have an open file.

llvm-svn: 184095

llvm-svn: 184092

llvm-svn: 184089

llvm-svn: 184087

llvm-svn: 184084

llvm-ar is the only tool that needs to write archive files. Every other tool
should be able to use the lib/Object interface.

llvm-svn: 184083

llvm-svn: 184081

llvm-svn: 184080

This broke for example the 'not' utility, if a directory called
'FileCheck' is executable and in the path before the actual 'FileCheck'.

This patch steals the implementation of the "old" PathV1 canExecute
implementation:
- checks for R_OK (file readable): this is necessary for executing
  scripts; we should not regress here unless we have good reasons
- checks for S_ISREG; if we want to get rid of this, we'd need to
  change all callers who already made the assumption when depending
  on Path V1.

llvm-svn: 184074

llvm-objdump should provide some way of printing out the addends present in the
.rela sections for debugging purposes if nothing else.

llvm-svn: 184072

Frame index handling is now target-agnostic, so delete the target hooks
for creation & asm printing of target-specific addressing in DBG_VALUEs
and any related functions.

llvm-svn: 184067

Rather than using the full power of target-specific addressing modes in
DBG_VALUEs with Frame Indicies, simply use Frame Index + Offset. This
reduces the complexity of debug info handling down to two
representations of values (reg+offset and frame index+offset) rather
than three or four.

Ideally we could ensure that frame indicies had been eliminated by the
time we reached an assembly or dwarf generation, but I haven't spent the
time to figure out where the FIs are leaking through into that & whether
there's a good place to convert them. Some FI+offset=>reg+offset
conversion is done (see PrologEpilogInserter, for example) which is
necessary for some SelectionDAG assumptions about registers, I believe,
but it might be possible to make this a more thorough conversion &
ensure there are no remaining FIs no matter how instruction selection
is performed.

llvm-svn: 184066

This currently unused function appeared to be asserting in the wrong
direction - DebugValues are never definitions of registers, only uses.
Curiously we don't perform any of these checks for the more common (&
actually used) case of MachineOperand::CreateReg (or other Create
functions).

llvm-svn: 184065

llvm-svn: 184059