If globals can be unnamed, there is no reason for aliases to be different.

The restriction was there since the original implementation in r36435. I
can only guess it was there because of the old bison parser for the old
alias syntax.

llvm-svn: 239921

Fixes one instance of PR17960.

llvm-svn: 239920

llvm-svn: 239919

llvm-svn: 239918

[Hexagon] Adding some compare tests, fixing existing XFAILed tests, and removing mcpu=hexagonv4 since that's the minimum version anyway.

llvm-svn: 239917

llvm-svn: 239916

Tweak test cases and rename headerIndexFor -> getHeaderIndex.

llvm-svn: 239915

Directional labels can show up in symbol tables (and we have a llvm-mc test for
that). Given that, we need to make sure they are named.

With that out of the way, use setUseNamesOnTempLabels in llvm-mc so that it
too benefits from the memory saving.

llvm-svn: 239914

llvm-svn: 239913

Currently, OMPT support requires the weak attribute which isn't supported
on Windows.  This patch has CMake error out when LIBOMP_OMPT_SUPPORT=true
and the users is building on Windows.
http://lists.cs.uiuc.edu/pipermail/openmp-dev/2015-June/000692.html

Patch by Jonas Hahnfeld

llvm-svn: 239912

This matches GNU as output.

llvm-svn: 239911

Reviewers: dsanders

Reviewed By: dsanders

Subscribers: llvm-commits

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

llvm-svn: 239910

llvm-svn: 239909

Current approach for initial-exec in ELF/x86_64 is to create a GOT entry
and change the relocation to R_X86_64_PC32 to be handled as a GOT offfset.
However there are two issues with this approach: 1. the R_X86_64_PC32 is
not really required since the GOT relocation will be handle dynamically and
2. the TLS symbols are not being exported externally and then correct
realocation are not being applied.

This patch fixes the R_X86_64_GOTTPOFF handling by just emitting a
R_X86_64_TPOFF64 dynamically one; it also sets R_X86_64_TPOFF64 to be
handled by runtime one.  For second part, the patches uses a similar
strategy used for aarch64, by reimplementing buildDynamicSymbolTable
from X86_64ExecutableWriter and adding the TLS symbols in the dynamic
symbol table.

Some tests had to be adjusted due the now missing R_X86_64_PC32 relocation.
With this test the simple testcase:

* t1.c:

__thread int t0;
__thread int t1;
__thread int t2;
__thread int t3;

* t0.c:

extern __thread int t0;
extern __thread int t1;
extern __thread int t2;
extern __thread int t3;

__thread int t4;
__thread int t5;
__thread int t6;
__thread int t7;

int main ()
{
  t0 = 1;
  t1 = 2;
  t2 = 3;
  t3 = 4;

  t4 = 5;
  t5 = 6;
  t6 = 7;
  t7 = 8;

  printf ("%i %i %i %i\n", t0, t1, t2, t3);
  printf ("%i %i %i %i\n", t4, t5, t6, t7);

  return 0;
}

Shows correct output for x86_64.

llvm-svn: 239908

llvm-svn: 239907

This patch fixes the wrong .tbss segment size generated for cases where
multiple modules have non initialized threads variables.  For instance:

* t0.c

__thread int x0;
__thread int x1;
__thread int x2;

extern __thread int e0;
extern __thread int e1;
extern __thread int e2;
extern __thread int e3;

int foo0 ()
{
  return x0;
}

int main ()
{
  return x0;
}

* t1.c

__thread int e0;
__thread int e1;
__thread int e2;
__thread int e3;


lld is generating (for aarch64):

  [14] .tbss             NOBITS           0000000000401000  00001000
       0000000000000010  0000000000000000 WAT       0     0     4

Where is just taking in consideration the largest tbss segment, not all
from all objects.  ld generates a correct output:

  [17] .tbss             NOBITS           0000000000410dec  00000dec
       000000000000001c  0000000000000000 WAT       0     0     4

This issue is at 'lib/ReaderWriter/ELF/SegmentChunks.cpp' where
Segment<ELFT>::assignVirtualAddress is setting wrong slice values, not taking care
of although tbss segments file size does noy play role in other segment virtual
address placement, its size should still be considered.

llvm-svn: 239906

Summary:
This does not include support for the immediate variants of these pseudo-instructions.
Fixes llvm.org/PR20968.

Reviewers: dsanders

Reviewed By: dsanders

Subscribers: seanbruno, emaste, llvm-commits

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

llvm-svn: 239905

llvm-svn: 239904

llvm-svn: 239903

Summary:
Qualify all types used in AST matcher macros. This makes it possible to
put AST matchers in user code into a namespace other than clang::ast_matchers
and this way prevent ODR violations that could happen when a matcher with the
same name is defined in multiple translation units. Updated comments
accordingly.

Reviewers: djasper, klimek

Reviewed By: djasper, klimek

Subscribers: klimek, cfe-commits

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

llvm-svn: 239902

Summary:
Call MCSymbolRefExpr::create() with a MCSymbol* argument, not with a StringRef
of the Symbol's name, in order to avoid creating invalid temporary symbols for
relative labels (e.g. {$,.L}tmp00, {$,.L}tmp10 etc.).

Reviewers: dsanders

Reviewed By: dsanders

Subscribers: llvm-commits

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

llvm-svn: 239901

Patch by Mathieu Champlon. Thank you.

llvm-svn: 239900

Reviewers: dsanders

Reviewed By: dsanders

Subscribers: llvm-commits

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

llvm-svn: 239899

llvm-svn: 239898

Summary:
Previously, MCSymbolRefExpr::create() was called with a StringRef of the symbol
name, which it would then search for in the Symbols StringMap (from MCContext).

However, relative labels (which are temporary symbols) are apparently not stored
in the Symbols StringMap, so we end up creating a new {$,.L}tmp symbol
({$,.L}tmp00, {$,.L}tmp10 etc.) each time we create an MCSymbolRefExpr by
passing in the symbol name as a StringRef.

Fortunately, there is a version of MCSymbolRefExpr::create() which takes an
MCSymbol* and we already have an MCSymbol* at that point, so we can just pass
that in instead of the StringRef.

I also removed the local StringRef calls to MCSymbolRefExpr::create() from
expandMemInst(), as those cases can be handled by evaluateRelocExpr() anyway.

Reviewers: dsanders

Reviewed By: dsanders

Subscribers: llvm-commits

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

llvm-svn: 239897

llvm-svn: 239896

llvm-svn: 239895

This makes this consistent with non-typescript enums.

Also shuffle the language-dependent stuff in mustBreakBefore to a
single location.

Patch initiated by Martin Probst.

llvm-svn: 239894

Patch by Martin Probst.

Before:
  enum {
    A,
    B
  } var x = 1;

After:
  enum {
    A,
    B
  }
  var x = 1;

llvm-svn: 239893

starts with a given sequence of tokens. Only the one-token version is
used yet, but other usages are coming up momentarily.

llvm-svn: 239892

AliasAnalysis by getting it from its newly canonical home of
MemoryLocation::UnknownSize.

llvm-svn: 239890

llvm-svn: 239889

Change builtin function name and signature ( add third parameter - rounding mode ).
Added tests for intrinsics.

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

llvm-svn: 239888

names for counts with the word 'Count' to make them less ambiguous.

This will be an actual error if we use unscoped enums for any of these,
and generally this seems much clearer to read.

Also, use clang-format to normalize the formatting of this code which
seems to have been needlessly odd.

No functionality changed here.

llvm-svn: 239887

This is now living in MemoryLocation, which is what it pertains to. It
is also an enum there rather than a static data member which is left
never defined.

llvm-svn: 239886

that it is its own entity in the form of MemoryLocation, and update all
the callers.

This is an entirely mechanical change. References to "Location" within
AA subclases become "MemoryLocation", and elsewhere
"AliasAnalysis::Location" becomes "MemoryLocation". Hope that helps
out-of-tree folks update.

llvm-svn: 239885

virtual interface on AliasAnalysis only deals with ModRef information.

This interface was both computing memory locations by using TLI and
other tricks to estimate the size of memory referenced by an operand,
and computing ModRef information through similar investigations. This
change narrows the scope of the virtual interface on AliasAnalysis
slightly.

Note that all of this code could live in BasicAA, and be done with
a single investigation of the argument, if it weren't for the fact that
the generic code in AliasAnalysis::getModRefBehavior for a callsite
calls into the virtual aspect of (now) getArgModRefInfo. But this
patch's arrangement seems a not terrible way to go for now.

The other interesting wrinkle is how we could reasonably extend LLVM
with support for custom memory location sizes and mod/ref behavior for
library routines. After discussions with Hal on the review, the
conclusion is that this would be best done by fleshing out the much
desired support for extensions to TLI, and support these types of
queries in that interface where we would likely be doing other library
API recognition and analysis.

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

llvm-svn: 239884

This involved removing the conditional inclusion and replacing them
with target attributes matching the original conditional inclusion
and checks. The testcase update removes the macro checks for each
file and replaces them with usage of the __target__ attribute, e.g.:

int __attribute__((__target__(("sse3")))) foo(int a) {
  _mm_mwait(0, 0);
  return 4;
}

This usage does require the enclosing function have the requisite
__target__ attribute for inlining and code generation - also for
any macro intrinsic uses in the enclosing function. There's no change
for existing uses of the intrinsic headers.

llvm-svn: 239883

This is a precursor to changing them to use the new target attribute
code.

llvm-svn: 239882

The following code is generated for reduction clause within 'omp simd' loop construct:
#pragma omp simd reduction(op:var)
for (...)
  <body>

alloca priv_var
priv_var = <initial reduction value>;
<loop_start>:
<body> // references to original 'var' are replaced by 'priv_var'
<loop_end>:
var op= priv_var;

llvm-svn: 239881