Google is re-licensing this code under the standard dual license of
compiler-rt.

llvm-svn: 204128

llvm-svn: 204127

still experimental

llvm-svn: 204126

llvm-svn: 204125

llvm-svn: 204124

[C++11] Mark the target fast isel classes as 'final' so that the compiler can de-virtualize some of the internal calls.

llvm-svn: 204123

llvm-svn: 204122

llvm-svn: 204121

[C++11] Change the interface of getCOFF{Section,Relocation,Symbol} to make it work with range-based for loops.

Reviewers: ruiu

Reviewed By: ruiu

CC: llvm-commits

Differential Revision: http://llvm-reviews.chandlerc.com/D3097

llvm-svn: 204120

llvm-svn: 204119

  V_CNDMASK_B32_e64 v0, v0, -1.#QNAN0e+00, s[2:3], 0, 0, 0, 0

FIXME: We really need to implement our formatter...
llvm-svn: 204118

llvm-svn: 204117

llvm-svn: 204116

llvm-svn: 204115

Add an assertion that a valid section is referenced.  The potential NULL pointer
dereference was identified by the clang static analyzer.

llvm-svn: 204114

This checks that parameters named in comments that appear before arguments in
function and constructor calls match the parameter name used in the callee's
declaration. For example:

void f(int x, int y);

void g() {
  f(/*y=*/0, /*z=*/0);
}

contains two violations of the policy, as the names 'x' and 'y' used in the
declaration do not match names 'y' and 'z' used at the call site.

I think there is significant value in being able to check/enforce this policy
as a way of guarding against accidental API misuse and silent breakages
caused by API changes.

Although this pattern appears somewhat frequently in the LLVM codebase,
this policy is not prescribed by the LLVM coding standards at the moment,
so it lives under 'misc'.

Differential Revision: http://llvm-reviews.chandlerc.com/D2914

llvm-svn: 204113

The standard JIT has been discarded in favour of MCJIT.  USE_STANDARD_JIT is no
longer defined.  Furthermore, the execution engine is now built in
IRExecutionUnit.  Simply remove inclusion of both JIT headers.

llvm-svn: 204112

Update gitignore to ignore additional temporary files and format more similar to
LLVM's .gitignore.

llvm-svn: 204111

Multichar constants are not portable as the byte order is undefined.  Use a
constant value instead.  This avoids a warning when compiling with gcc 4.8+
(-Wmultichar) and makes the code more portable.

llvm-svn: 204110

llvm-svn: 204109

llvm-svn: 204108

This is a follow-up to r203983 based on feedback from dblaikie and mren (Thanks!)
No functionality change.

llvm-svn: 204107

This allows us to catch more opportunities for ODR-based type uniquing
during LTO.
Paired commit with CFE which updates some testcases to verify the new
DIBuilder behavior.

llvm-svn: 204106

store DIRefs to their types for improved type uniquing.

llvm-svn: 204105

llvm-svn: 204104

llvm-svn: 204103

No functional change.

llvm-svn: 204102

DebugInfo: Avoid emitting standard opcode lengths in debug_line.dwo headers where opcodes are never used anyway

Introduce a slightly tighter wrapper around the header structure that
handles this use case. (MCDwarfDwoLineTable)

llvm-svn: 204101

template specialization (from different modules), dump them all, so that every
declaration is dumped somewhere.

llvm-svn: 204100

This removes an attribute (and more importantly, a relocation) from
skeleton type units and removes some unnecessary file names from the
debug_line section that remains in the .o (and linked executable) file.

There's still a few places we could shave off some more space here:

* use compilation dir of the underlying compilation unit (since all the
  type units share that compilation dir - though this would be more
  complicated in LTO cases where they don't (keep a map of compilation
  dir->line table header?))

* Remove some of the unnecessary header fields from the line table since
  they're not needed in this situation (about 12 bytes per table).

llvm-svn: 204099

llvm-svn: 204098

loops, it was making this an error, resulting in buildbot failures.

llvm-svn: 204097

llvm-svn: 204096

Cleans up buildbot failures on R600 and similar.

llvm-svn: 204095

DebugInfo: Do not rely on the compilation dir (index 0) for files in line tables shared between compilation units

When emitting assembly there's no support for emitting separate line
tables for each compilation unit - so LLVM emits .loc directives
producing a single line table.

Line tables have an implicit directory (index 0) equal to the
compilation directory (DW_AT_comp_dir) of the compilation unit that
references them.

If multiple compilation units (with possibly disparate compilation
directories) reference the same line table, we must avoid relying on
this ambiguous directory.

Achieve this my simply not setting the compilation directory on the line
table when we're in this situation (multiple units while emitting
assembly).

llvm-svn: 204094

in class extension is being implemented in primary class implementation
(no overriding is involved).
// rdar://16249335

llvm-svn: 204093

We still do a few lookups into the line table mapping in MCContext that
could be factored out into a single lookup (rather than looking it up
once for the table label, once to set the compilation unit, once for
each time we need a file ID, etc... ) but assembly output complicates
that somewhat as we still need a virtual dispatch back to the
MCAsmStreamer in that case.

llvm-svn: 204092

Reapply r204079 and r204083, this time with stubs for fputc in
compiler-rt.

llvm-svn: 204091

llvm-svn: 204090

Our handling of compilation directory in DwarfDebug was broken
(incorrectly using the 'last' compilation directory (that of the last
CU in the metadata list) for all function emission in any CU). By moving
this handling down into MCDwarf the issue is fixed as the compilation
dir is tracked correctly per line table.

llvm-svn: 204089