Add the next codegen for 'omp cancel' directive:
if (__kmpc_cancel()) {
  __kmpc_cancel_barrier();
  <exit construct>;
}

llvm-svn: 241429

an existing using shadow declaration if they define entities of the same kind
in different namespaces.

We'd previously check this consistently if the using-declaration came after the
other declaration, but not if it came before.

llvm-svn: 241428

Before every test was using a section with an address of zero.

llvm-svn: 241427

TLS table header field is supposed to have address and size of TLS table.
The linker doesn't have to understand what TLS table is. TLS table's name
is always "_tls_used", so if there's that symbol, the linker simply sets
that symbol's RVA to the header. The size of the TLS table is always 40 bytes.

llvm-svn: 241426

llvm-svn: 241425

When we see something that looks like a constructor with a return type, only issue one error, not two.

llvm-svn: 241424

llvm-svn: 241423

llvm-svn: 241422

llvm-svn: 241421

This function is called SymbolTable::readObjects, so in order to
parallelize that function, we have to make this function thread-safe.

llvm-svn: 241420

llvm-svn: 241419

llvm-svn: 241418

Note that the linker is not multi-threaded yet.
This is a preparation for that.

llvm-svn: 241417

In the new design, mutation of Symbol pointers is the name resolution
operation. This patch makes them atomic pointers so that they can
be mutated by multiple threads safely. I'm going to use atomic
compare-exchange on these pointers.

dyn_cast<> doesn't recognize atomic pointers as pointers,
so we need to call load(). This is unfortunate, but in other places
automatic type conversion works fine.

llvm-svn: 241416

llvm-svn: 241415

Differential Revision: http://reviews.llvm.org/D10945

llvm-svn: 241414

From the linker's perspective, an available_externally global is equivalent
to an external declaration (per isDeclarationForLinker()), so it is incorrect
to consider it to be a weak definition.

Also clean up some logic in the dead argument elimination pass and clarify
its comments to better explain how its behavior depends on linkage,
introduce GlobalValue::isStrongDefinitionForLinker() and start using
it throughout the optimizers and backend.

Differential Revision: http://reviews.llvm.org/D10941

llvm-svn: 241413

llvm-svn: 241412

There is some functional change here because it changes target code from
atoi(3) to StringRef::getAsInteger which has error checking. For valid
constraints there should be no difference.

llvm-svn: 241411

Merged arch/target into a specific triple - we had i686 and x86_64 targets overriding each other....

llvm-svn: 241410

corei7 is capable of a lot more than just SSE2.... 

llvm-svn: 241409

llvm-svn: 241408

llvm-svn: 241407

include encoding and intrinsics tests.

review
http://reviews.llvm.org/D10896

llvm-svn: 241406

llvm-svn: 241405

Correctly support assembling "pushw $imm8" on x86-64 targets. 
Also some cleanup of the PUSH instructions (PUSH64i16 and PUSHi16 actually
represent the same instruction)

This fixes PR23996

Patch by: david.l.kreitzer@intel.com
Differential Revision: http://reviews.llvm.org/D10878

llvm-svn: 241404

CMake-2.8.12 is hardcoded to create symlinked clang.exe if the target property VERSION is present and the host is not Win32.
Then clang.exe-*.* is generated and clang.exe is symlinked to it.

  lrwxrwxrwx. 1 bb bb      13 Jul  5 18:04 clang.exe -> clang.exe-3.7
  -rwxr-x---. 1 bb bb  244763 Jul  5 18:04 clang++.exe
  -rwxr-x---. 1 bb bb  244763 Jul  5 18:04 clang.exe-3.7

It made me unhappy when built binaries were copied to the Windows target.

FIXME: Could we just remove the target property VERSION in add_llvm_executable() ?
llvm-svn: 241403

[CMake] add_llvm_symbol_exports: Use Python oneliner instead of "cmd.exe /c type" to generate *.def.

llvm-svn: 241402

llvm-svn: 241401

llvm-svn: 241400

This patch corresponds to review:
http://reviews.llvm.org/D10875

The bulk of the second round of additions to altivec.h.
The following interfaces were added:
vector double vec_floor(vector double)
vector double vec_madd(vector double, vector double, vector double)
vector float vec_msub(vector float, vector float, vector float)
vector double vec_msub(vector double, vector double, vector double)
vector float vec_mul(vector float, vector float)
vector double vec_mul(vector double, vector double)
vector float vec_nmadd(vector float, vector float, vector float)
vector double vec_nmadd(vector double, vector double, vector double)
vector double vec_nmsub(vector double, vector double, vector double)
vector double vec_nor(vector double, vector double)
vector double vec_or(vector double, vector double)
vector float vec_rint(vector float)
vector double vec_rint(vector double)
vector float vec_nearbyint(vector float)
vector double vec_nearbyint(vector double)
vector float vec_sqrt(vector float)
vector double vec_sqrt(vector double)
vector double vec_rsqrte(vector double)
vector double vec_sel(vector double, vector double, vector unsigned long long)
vector double vec_sel(vector double, vector double, vector unsigned long long)
vector double vec_sub(vector double, vector double)
vector double vec_trunc(vector double)
vector double vec_xor(vector double, vector double)
vector double vec_xor(vector double, vector bool long long)
vector double vec_xor(vector bool long long, vector double)

New VSX paths for the following interfaces:
vector float vec_madd(vector float, vector float, vector float)
vector float vec_nmsub(vector float, vector float, vector float)
vector float vec_rsqrte(vector float)
vector float vec_trunc(vector float)
vector float vec_floor(vector float)

llvm-svn: 241399

This patch corresponds to review:
http://reviews.llvm.org/D10874

Back end portion of the second round of additions to altivec.h.

llvm-svn: 241398

llvm-svn: 241397

/merge:.foo=.bar makes the linker to merge section .foo with section .bar.

llvm-svn: 241396

llvm-svn: 241395

Followup to D10433 and D10589 that fixes i8/i16 uint2fp vector conversions by zero extending to i32 and using the sint2fp path (unless the target does actually support uint2fp).

llvm-svn: 241394

Although this does cut the number of traces recomputed by ~10% for the
test case mentioned in http://reviews.llvm.org/D10460, it doesn't
make a dent in the overall performance. That example needs to be more
selective when invalidating traces.

llvm-svn: 241393

llvm-svn: 241392

We were previously hitting assertion failures in the writer in cases where
a regular object file defined a weak external symbol that was defined by
a bitcode file. Because /export and /entry name mangling were implemented
using weak externals, the same problem affected mangled symbol names in
bitcode files.

The underlying cause of the problem was that weak external symbols were
being resolved before doing LTO, so the symbol table may have contained stale
references to bitcode symbols. The fix here is to defer weak external symbol
resolution until after LTO.

Also implement support for weak external symbols in bitcode files
by modelling them as replaceable DefinedBitcode symbols.

Differential Revision: http://reviews.llvm.org/D10940

llvm-svn: 241391

Summary: Use string::find(char) for single character strings.

Reviewers: abidh, ki.stfu, clayborg

Subscribers: lldb-commits

Differential Revision: http://reviews.llvm.org/D10943

llvm-svn: 241390