I accidently introduced those in r227319.

llvm-svn: 227339

llvm-svn: 227338

It's an empty shell for now. It's main method just opens the debug
map objects and parses their Dwarf info. Test that we at least do
that correctly.

llvm-svn: 227337

llvm-svn: 227336

llvm-svn: 227335

llvm-svn: 227334

llvm-svn: 227333

[Hexagon] Replacing XTYPE/SHIFT intrinsic patternss.  Adding tests and missing instructions with tests.

llvm-svn: 227330

Launch lldb-gdbserver in same process group when launched remotely using lldb-platform - commit on behalf of flackr.

http://reviews.llvm.org/D7211

llvm-svn: 227329

llvm-svn: 227327

asan_symbolize.py isn't needed on Windows, but it's nice if asan has a unified
UI on all platforms. So rather than have asan_symolize.py die on startup due to
it importing modules that don't exist on Windows, let it just echo the input.

llvm-svn: 227326

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

llvm-svn: 227325

llvm-svn: 227322

llvm-svn: 227321

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

llvm-svn: 227320

Summary:
MetadataAsValue uses a canonical format that strips the MDNode if it
contains only a single constant value. This triggers an assertion when
trying to cast the value to a MDNode.

Subscribers: llvm-commits

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

llvm-svn: 227319

The `Addend` is an optional field of the `Relocation` YAML record. But
we do not provide its default value while reading it from a YAML file
and so it might keep uninitialized.

I am going to fix the code by a separate commit. We might either make
this field mandatory (at least for .rela sections) or specify 0 as
a default value explicitly.

llvm-svn: 227318

TCRETURNmi64, which was mistakenly changed in r227307 will wait for another day.

llvm-svn: 227317

This is a follow up to r227113.

It is now required to use the amdgcn target for SI and newer GPUs.

llvm-svn: 227316

llvm-svn: 227315

llvm-svn: 227314

Patch by Mingjie Xing.

llvm-svn: 227313

make new diagnostic an ExtWarn

llvm-svn: 227312

As the AggressiveAntiDepBreaker iterated backward through a scheduling region,
we must leave super registers live through subregister definitions so that all
relevant subregister definitions are renamed together. The problem was that we
were also discarding sub-register use locations as the sub-registers are
redefined. The result is that we'd rename the super register along with some,
but not all, subregister definitions.

  R0_D = {R0_L, R1_L}
  R0_L = {R0_S, R1_S}

  %R0_L<def> = TRLi9 16, pred:8, pred:%noreg
  %R1_L<def> = LSRLrr %R1_L<kill>, %R0_S, pred:8, pred:%noreg
  %R0_L<def> = LSRLrr %R2_L, %R0_S, pred:8, pred:%noreg, %R0_L<imp-use,kill>
  %R1_L<def> = ANDLri %R1_L<kill>, 2047, pred:8, pred:%noreg
  %R0_L<def> = ANDLri %R0_L<kill>, 2047, pred:8, pred:%noreg
  %R4_D<def> = ASRDrr %R0_D<kill>, %R6_S

  Anti:   %R4_D<def> = ASRDrr %R0_D<kill>, %R6_S
   Def Groups: R4_D=g213->g215(via R4_S)->g214(via R4_L)->g216(via R5_S)->g216(via R4_L)->g217(via R5_L)
   Use Groups: R0_D=g0->g218(last-use) R1_L->g219(last-use) R6_S=g204->g220(last-use)
  Anti:   %R0_L<def> = ANDLri %R0_L<kill>, 2047, pred:8, pred:%noreg
   Def Groups: R0_L=g208->g209(via R0_S)->g218(via R0_D)->g210(via R1_S)->g210(via R0_D)
   Antidep reg: R0_L (real dependency)
   Use Groups: R0_L=g210->g224(last-use) R0_S->g225(last-use) R1_S->g226(last-use)
  Anti:   %R1_L<def> = ANDLri %R1_L<kill>, 2047, pred:8, pred:%noreg
   Def Groups: R1_L=g219->g210(via R0_D)
   Antidep reg: R1_L (real dependency)
   Use Groups: R1_L=g210->g229(last-use)
  Anti:   %R0_L<def> = LSRLrr %R2_L, %R0_S, pred:8, pred:%noreg, %R0_L<imp-use,kill>
   Def Groups: R0_L=g224->g225(via R0_S)->g210(via R0_D)->g226(via R1_S)->g226(via R0_D)
   Antidep reg: R0_L Use Groups: R2_L=g192 R0_S=g226->g230(last-use) R0_L=g226->g231(last-use) R1_S->g232(last-use)
  Anti:   %R1_L<def> = LSRLrr %R1_L<kill>, %R0_S, pred:8, pred:%noreg
   Def Groups: R1_L=g229->g226(via R0_D)
   Antidep reg: R1_L Use Groups: R1_L=g226->g233(last-use) R0_S=g230
  Anti:   %R0_L<def> = TRLi9 16, pred:8, pred:%noreg
   Def Groups: R0_L=g231->g230(via R0_S)->g226(via R0_D)->g232(via R1_S)->g232(via R0_D)
   Antidep reg: R0_L
   Rename Candidates for Group g232:
    R0_D: elcInt64Regs :: R0_D R1_D R2_D R3_D R4_D R5_D R8_D R9_D R10_D R11_D R12_D R13_D R14_D R15_D R16_D R17_D R18_D R19_D R20_D R21_D R22_D R23_D R24_D R25_D
    R0_L: elcIntRegs :: R0_L R1_L R2_L R3_L R4_L R5_L R8_L R9_L R10_L R11_L R12_L R13_L R14_L R15_L R16_L R17_L R18_L R19_L R20_L R21_L R22_L R23_L R24_L R25_L
    R0_S: elcShrtRegs elcShrtRegs :: R0_S R1_S R2_S R3_S R4_S R5_S R8_S R9_S R10_S R11_S R12_S R13_S R14_S R15_S R16_S R17_S R18_S R19_S R20_S R21_S R22_S R23_S R24_S R25_S
   Find Registers: [R12_D: R12_D R12_L R12_S]
   Breaking anti-dependence edge on R0_L: R0_D->R12_D(1 refs) R0_L->R12_L(2 refs) R0_S->R12_S(2 refs)
   Use Groups:
  ...

  %R12_L<def> = TRLi9 16, pred:8, pred:%noreg
  %R1_L<def> = LSRLrr %R1_L<kill>, %R12_S, pred:8, pred:%noreg
  %R0_L<def> = LSRLrr %R2_L<kill>, %R12_S, pred:8, pred:%noreg, %R12_L<imp-use>
  %R1_L<def> = ANDLri %R1_L<kill>, 2047, pred:8, pred:%noreg
  %R0_L<def> = ANDLri %R0_L<kill>, 2047, pred:8, pred:%noreg
  %R4_D<def> = ASRDrr %R12_D<kill>, %R6_S

With this change, we now produce:

  Anti:   %R4_D<def> = ASRDrr %R0_D<kill>, %R6_S
   Def Groups: R4_D=g213->g215(via R4_S)->g214(via R4_L)->g216(via R5_S)->g216(via R4_L)->g217(via R5_L)
   Use Groups: R0_D=g0->g218(last-use) R1_L->g219(last-use) R6_S=g204->g220(last-use)
  Anti:   %R0_L<def> = ANDLri %R0_L<kill>, 2047, pred:8, pred:%noreg
   Def Groups: R0_L=g208->g209(via R0_S)->g218(via R0_D)->g210(via R1_S)->g210(via R0_D)
   Antidep reg: R0_L (real dependency)
   Use Groups: R0_L=g210
  Anti:   %R1_L<def> = ANDLri %R1_L<kill>, 2047, pred:8, pred:%noreg
   Def Groups: R1_L=g219->g210(via R0_D)
   Antidep reg: R1_L (real dependency)
   Use Groups: R1_L=g210
  Anti:   %R0_L<def> = LSRLrr %R2_L, %R0_S, pred:8, pred:%noreg, %R0_L<imp-use,kill>
   Def Groups: R0_L=g210->g210(via R0_D)->g210(via R0_D)
   Antidep reg: R0_L Use Groups: R2_L=g192 R0_S=g210 R0_L=g210
  Anti:   %R1_L<def> = LSRLrr %R1_L<kill>, %R0_S, pred:8, pred:%noreg
   Def Groups: R1_L=g210->g210(via R0_D)
   Antidep reg: R1_L Use Groups: R1_L=g210 R0_S=g210
  Anti:   %R0_L<def> = TRLi9 16, pred:8, pred:%noreg
   Def Groups: R0_L=g210->g210(via R0_D)->g210(via R0_D)
   Antidep reg: R0_L
   Rename Candidates for Group g210:
    R0_D: elcInt64Regs :: R0_D R1_D R2_D R3_D R4_D R5_D R8_D R9_D R10_D R11_D R12_D R13_D R14_D R15_D R16_D R17_D R18_D R19_D R20_D R21_D R22_D R23_D R24_D R25_D
    R0_L: elcIntRegs elcIntAIRegs elcIntRegs elcIntRegs elcIntRegs elcIntRegs :: R0_L R1_L R2_L R3_L R4_L R5_L R8_L R9_L R10_L R11_L R12_L R13_L R14_L R15_L R16_L R17_L R18_L R19_L R20_L R21_L R22_L R23_L R24_L R25_L
    R1_L: elcIntRegs elcIntRegs elcIntRegs elcIntRegs elcIntRegs :: R0_L R1_L R2_L R3_L R4_L R5_L R8_L R9_L R10_L R11_L R12_L R13_L R14_L R15_L R16_L R17_L R18_L R19_L R20_L R21_L R22_L R23_L R24_L R25_L
    R0_S: elcShrtRegs elcShrtRegs :: R0_S R1_S R2_S R3_S R4_S R5_S R8_S R9_S R10_S R11_S R12_S R13_S R14_S R15_S R16_S R17_S R18_S R19_S R20_S R21_S R22_S R23_S R24_S R25_S
   Find Registers: [R12_D: R12_D R12_L R13_L R12_S]
   Breaking anti-dependence edge on R0_L: R0_D->R12_D(1 refs) R0_L->R12_L(7 refs) R1_L->R13_L(5 refs) R0_S->R12_S(2 refs)
   Use Groups:
  ...

  %R12_L<def> = TRLi9 16, pred:8, pred:%noreg
  %R13_L<def> = LSRLrr %R13_L<kill>, %R12_S, pred:8, pred:%noreg
  %R12_L<def> = LSRLrr %R2_L<kill>, %R12_S<kill>, pred:8, pred:%noreg, %R12_L<imp-use,kill>
  %R13_L<def> = ANDLri %R13_L<kill>, 2047, pred:8, pred:%noreg
  %R12_L<def> = ANDLri %R12_L<kill>, 2047, pred:8, pred:%noreg
  %R4_D<def> = ASRDrr %R12_D, %R6_S, %R12_L<imp-def>, %R12_S<imp-def>, %R13_S<imp-def>

As demonstrated by this example, this is also somewhat unfortunate, because
there is actually no need to rename the super register in this case (it is
fully covered by later subregister definitions), but we don't seem to track
enough information here to exploit that either.

Thanks to Daniil Troshkov for reporting the issue. The debug outputs in this
commit message are from Daniil.

llvm-svn: 227311

Without this patch, this test was accidentally testing that
CLANG_RESOURCE_DIR, CLANG_LIBDIR_SUFFIX, and CLANG_VERSION_STRING
were set to a particular set of values.

The test was also getting pretty hairy since it was attempting to craft
a regular expression that covered "all" possible combinations of
settings for these configure-time constants.

Clean it up by directly capturing the resource directory in a FileCheck
variable.

llvm-svn: 227310

The code building the code completion string for overloads was providing
less detail compared to the one building completion strings for function
declarations. There was no information about optionals and no information
about what's a parameter and what's a function identifier, everything
besides ResultType, CurrentParameter and special characters was classified
as Text.

This makes code completion strings for overload candidates to follow a
pattern very similar, but not identical, to the one in use for function
declarations:

 - return type chunk: ResultType
 - function identifier chunk: Text
 - parameter chunks: Placeholder
 - optional parameter chunks: Optional
 - current parameter chunk: CurrentParameter

llvm-svn: 227309

Reduce integer multiplication by a constant of the form k*2^c, where k is in {3,5,9} into a lea + shl. Previously it was only done for imulq on 64-bit platforms, but it makes sense for imull and 32-bit as well.

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

llvm-svn: 227308

This includes two things:
1) Fix TCRETURNdi and TCRETURN64di patterns to check the right thing (LP64 as opposed to target bitness).
2) Allow LEA64_32 in MatchingStackOffset.

llvm-svn: 227307

Again, I'd like to emphasize to everyone that this sort of markup change
is *not* what you should be concerned about when writing docs. Focus on
*content*.

I applaud Chandler for focusing on the fantastic content of this new
section!

llvm-svn: 227305

llvm-svn: 227304

By Asaf Badouh and Elena Demikhovsky

Added special nodes for rounding: FMADD_RND, FMSUB_RND..
It will prevent merge between nodes with rounding and other standard nodes.

llvm-svn: 227303

llvm-svn: 227302

llvm-svn: 227301

tracing code.

Managed static was just insane overhead for this. We took memory fences
and external function calls in every path that pushed a pretty stack
frame. This includes a multitude of layers setting up and tearing down
passes, the parser in Clang, everywhere. For the regression test suite
or low-overhead JITs, this was contributing to really significant
overhead.

Even the LLVM ThreadLocal is really overkill here because it uses
pthread_{set,get}_specific logic, and has careful code to both allocate
and delete the thread local data. We don't actually want any of that,
and this code in particular has problems coping with deallocation. What
we want is a single TLS pointer that is valid to use during global
construction and during global destruction, any time we want. That is
exactly what every host compiler and OS we use has implemented for
a long time, and what was standardized in C++11. Even though not all of
our host compilers support the thread_local keyword, we can directly use
the platform-specific keywords to get the minimal functionality needed.
Provided this limited trial survives the build bots, I will move this to
Compiler.h so it is more widely available as a light weight if limited
alternative to the ThreadLocal class. Many thanks to David Majnemer for
helping me think through the implications across platforms and craft the
MSVC-compatible syntax.

The end result is *substantially* faster. When running llc in a tight
loop over a small IR file targeting the aarch64 backend, this improves
its performance by over 10% for me. It also seems likely to fix the
remaining regressions seen by JIT users with threading enabled.

This may actually have more impact on real-world compile times due to
the use of the pretty stack tracing utility throughout the rest of Clang
or LLVM, but I've not collected any detailed measurements.

llvm-svn: 227300

querying of the pass registry.

The pass manager relies on the static registry of PassInfo objects to
perform all manner of its functionality. I don't understand why it does
much of this. My very vague understanding is that this registry is
touched both during static initialization *and* while each pass is being
constructed. As a consequence it is hard to make accessing it not
require a acquiring some lock. This lock ends up in the hot path of
setting up, tearing down, and invaliditing analyses in the legacy pass
manager.

On most systems you can observe this as a non-trivial % of the time
spent in 'ninja check-llvm'. However, I haven't really seen it be more
than 1% in extreme cases of compiling more real-world software,
including LTO.

Unfortunately, some of the GPU JITs are seeing this taking essentially
all of their time because they have very small IR running through
a small pass pipeline very many times (at least, this is the vague
understanding I have of it).

This patch tries to minimize the cost of looking up PassInfo objects by
leveraging the fact that the objects themselves are immutable and they
are allocated separately on the heap and so don't have their address
change. It also requires a change I made the last time I tried to debug
this problem which removed the ability to de-register a pass from the
registry. This patch creates a single access path to these objects
inside the PMTopLevelManager which memoizes the result of querying the
registry. This is somewhat gross as I don't really know if
PMTopLevelManager is the *right* place to put it, and I dislike using
a mutable member to memoize things, but it seems to work.

For long-lived pass managers this should completely eliminate
the cost of acquiring locks to look into the pass registry once the
memoized cache is warm. For 'ninja check' I measured about 1.5%
reduction in CPU time and in total time on a machine with 32 hardware
threads. For normal compilation, I don't know how much this will help,
sadly. We will still pay the cost while we populate the memoized cache.
I don't think it will hurt though, and for LTO or compiles with many
small functions it should still be a win. However, for tight loops
around a pass manager with many passes and small modules, this will help
tremendously. On the AArch64 backend I saw nearly 50% reductions in time
to complete 2000 cycles of spinning up and tearing down the pipeline.
Measurements from Owen of an actual long-lived pass manager show more
along the lines of 10% improvements.

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

llvm-svn: 227299

This patch folds fcmp in some cases of interest in Julia. The patch adds a function CannotBeOrderedLessThanZero that returns true if a value is provably not less than zero. I.e. the function returns true if the value is provably -0, +0, positive, or a NaN. The patch extends InstructionSimplify.cpp to fold instances of fcmp where:
 - the predicate is olt or uge
 - the first operand is provably not less than zero
 - the second operand is zero
The motivation for handling these cases optimizing away domain checks for sqrt in Julia for common idioms such as sqrt(x*x+y*y)..

http://reviews.llvm.org/D6972

llvm-svn: 227298

No functional changes.

llvm-svn: 227297

This fixes PR22358.

llvm-svn: 227296

Pointer arithmetic is only makes sense if the pointee type is complete.

This fixes PR22361.

llvm-svn: 227295

abomination.

For starters, this API is incredibly slow. In order to lookup the name
of a pass it must take a memory fence to acquire a pointer to the
managed static pass registry, and then potentially acquire locks while
it consults this registry for information about what passes exist by
that name. This stops the world of LLVMs in your process no matter
how little they cared about the result.

To make this more joyful, you'll note that we are preserving many passes
which *do not exist* any more, or are not even analyses which one might
wish to have be preserved. This means we do all the work only to say
"nope" with no error to the user.

String-based APIs are a *bad idea*. String-based APIs that cannot
produce any meaningful error are an even worse idea. =/

I have a patch that simply removes this API completely, but I'm hesitant
to commit it as I don't really want to perniciously break out-of-tree
users of the old pass manager. I'd rather they just have to migrate to
the new one at some point. If others disagree and would like me to kill
it with fire, just say the word. =]

llvm-svn: 227294