Only supported since GCC 6 and Intel 17.0. However GCC 6.3.0 is
crashing on two of the tests, so disable them as well...

Differential Revision: https://reviews.llvm.org/D50085

llvm-svn: 338720

llvm-svn: 338719

There is no point to explicitly proccess the expressions this patch removes.
We already have a llvm_unreachable for the default case.

llvm-svn: 338718

I disabled more tests than necessary, this enables them.

llvm-svn: 338717

This adds the NAN checks suggested in PR37776:
https://bugs.llvm.org/show_bug.cgi?id=37776

If both operands to maxnum are NAN, that should get constant folded, so we don't 
have to handle that case. This is the same assumption as other FP ops in this
function. Returning 'false' is always conservatively correct.

Copying from the bug report:

Currently, we have this for "when is cannotBeOrderedLessThanZero 
(mustBePositiveOrNaN) true for maxnum":
               L
        -------------------
        | Pos | Neg | NaN |
   ------------------------
   |Pos |  x  |  x  |  x  |
   ------------------------
 R |Neg |  x  |     |  x  |
   ------------------------
   |NaN |  x  |  x  |  x  |
   ------------------------


The cases with (Neg & NaN) are wrong. We should have:

                L
        -------------------
        | Pos | Neg | NaN |
   ------------------------
   |Pos |  x  |  x  |  x  |
   ------------------------
 R |Neg |  x  |     |     |
   ------------------------
   |NaN |  x  |     |  x  |
   ------------------------

Differential Revision: https://reviews.llvm.org/D50081

llvm-svn: 338716

llvm-svn: 338715

llvm-svn: 338714

It does not seem that this code is alive.
I seems was needed previously but we fixed it.

If it is still needed, it needs new tests,
but for now I do not know how to trigger it,
and so I removed it.

llvm-svn: 338713

But with a write-only format, who can really say?

llvm-svn: 338712

Missed from @338703

llvm-svn: 338709

Code was never executed with our test cases,
though it is valid and I think we can always run it.
This improves code coverage.

llvm-svn: 338708

The way address space declarations for builtins currently work
is nearly useless. The code assumes the address spaces used for
builtins is a confusingly named "target address space" from user
code using __attribute__((address_space(N))) that matches
the builtin declaration. There's no way to use this to declare
a builtin that returns a language specific address space.
The terminology used is highly cofusing since it has nothing
to do with the the address space selected by the target to use
for a language address space.

This feature is essentially unused as-is. AMDGPU and NVPTX
are the only in-tree targets attempting to use this. The AMDGPU
builtins certainly do not behave as intended (i.e. all of the
builtins returning pointers can never compile because the numbered
address space never matches the expected named address space).

The NVPTX builtins are missing tests for some, and the others
seem to rely on an implicit addrspacecast.

Change the used address space for builtins based on a target
hook to allow using a language address space for a builtin.
This allows the same builtin declaration to be used for multiple
languages with similarly purposed address spaces (e.g. the same
AMDGPU builtin can be used in OpenCL and CUDA even though the
constant address spaces are arbitarily different).

This breaks the possibility of using arbitrary numbered
address spaces alongside the named address spaces for builtins.
If this is an issue we probably need to introduce another builtin
declaration character to distinguish language address spaces from
so-called "target address spaces".

llvm-svn: 338707

Summary:
Previously, clang-format would crash if it tried to wrap an overlong
single line comment, because two parts of the code inserted a break in
the same location.

    /** heregoesalongcommentwithnospace */

This wasn't previously noticed as it could only trigger for an overlong
single line comment that did have no breaking opportunities except for a
whitespace at the very beginning.

This also introduces a check for JavaScript to not ever wrap a comment
before an opening curly brace:

    /** @mods {donotbreakbeforethecurly} */

This is because some machinery parsing these tags sometimes supports
breaks before a possible `{`, but in some other cases does not.
Previously clang-format was careful never to wrap a line with certain
tags on it. The better solution is to specifically disable wrapping
before the problematic token: this allows wrapping and aligning comments
but still avoids the problem.

Reviewers: krasimir

Subscribers: cfe-commits

Differential Revision: https://reviews.llvm.org/D50177

llvm-svn: 338706

Some lit tests that call llvm-ar use the 'r' flag. If the target archive
already exists and is in a corrupt state, this can cause the test to fail. We
have added 'rm -f' calls before the llvm-ar calls to increase the
robustness of the tests.

Differential revision: https://reviews.llvm.org/D49184

llvm-svn: 338705

Corrected and simplified the help text.

It was clearly too difficult to maintain before (see e.g. @227296) making it
simpler and more consistent it should help people keep it up to date.

Differential Revision: https://reviews.llvm.org/D48577

llvm-svn: 338703

We don't need to use a map to store ResourceState objects. The number of
processor resources is known statically from the scheduling model. We can
therefore use a vector, and reserve a slot for each processor resource that we
want to simulate.
Every time the ResourceManager queries the ResourceState vector, the index to
the vector of ResourceState objects can be easily computed from the processor
resource mask.

This drastically reduces the time complexity of method ResourceManager::use() and
method ResourceManager::release(). This patch gives an average speedup of 12%.

llvm-svn: 338702

Summary: Non functional change.

Subscribers: tschuett, courbet, llvm-commits

Differential Revision: https://reviews.llvm.org/D50176

llvm-svn: 338701

llvm-svn: 338700

isHeaderSection can be useful I believe,
but probably not right now and not
for this case.

llvm-svn: 338699

Ensure we cover all paths for vector data as requested on D49248

llvm-svn: 338698

Patch by Konstantin Schwarz!

If more than a single output section is added to a PT_LOAD header,
only the first section should set the LMAOffset of the segment.
Otherwise, we get a load-address overlap error

Differential revision: https://reviews.llvm.org/D50133

llvm-svn: 338697

llvm-svn: 338696

Summary: In order to exploit the potential of LLVM's new ItaniumPartialDemangler for indexing in LLDB, we expect conceptual changes in the implementation of the InitNameIndexes function. Here is a unit test that aims at covering all relevant code paths in that function.

Reviewers: labath, jingham, JDevlieghere

Reviewed By: JDevlieghere

Subscribers: friss, teemperor, davide, clayborg, erik.pilkington, lldb-commits, mgorny

Differential Revision: https://reviews.llvm.org/D49909

llvm-svn: 338695

Summary: Add missing include guard LLVM_DEMANGLE_DEMANGLE_H in llvm/Demangle/Demangle.h

Reviewers: erik.pilkington

Subscribers: llvm-commits

Differential Revision: https://reviews.llvm.org/D50042

llvm-svn: 338694

llvm-svn: 338693

llvm-svn: 338689

Summary:
Was:

  int LongVariableName =
    veryLongFunctionNameThatExceeds80ColumnsRule(SomeParameter);

  int ShortVar = veryLongFunctionNameThatStillFitsIntoOneLine(SomeParameter)
    .nowThisDoesntFit()
    .andThis()

Now:

  int LongVariableName =
      veryLongFunctionNameThatExceeds80ColumnsRule(SomeParameter);

  int ShortVar = veryLongFunctionNameThatStillFitsIntoOneLine(SomeParameter)
                     .nowThisDoesntFit()
                     .andThis()


Reviewers: espindola, MaskRay

Reviewed By: MaskRay

Subscribers: greened, llvm-commits

Differential Revision: https://reviews.llvm.org/D49726

llvm-svn: 338686

This is logical continuation of https://reviews.llvm.org/D46018 (r332449)

Differential Revision: https://reviews.llvm.org/D49660

llvm-svn: 338685

Patch by Konstantin Schwarz!

If both the MemRegion and LMARegion are set for an output section in
a linker script, we should only increase the LMARegion if it is
different from the MemRegion. Otherwise, we reserve the memory twice.

Differential revision: https://reviews.llvm.org/D50065

llvm-svn: 338684

llvm-svn: 338682

Patch by Konstantin Schwarz!

The condition to create a new phdr must also check the usage of "AT>" 
linker script command, and create a new PT_LOAD header if a new LMARegion is used.

This fixes PR38307

Differential revision: https://reviews.llvm.org/D50052

llvm-svn: 338679

llvm-svn: 338677

Adds some cleaned up debug messages from back when I was writing this.
Hopefully useful to others (and myself) as to why unroll and jam is not
transforming as expected.

Differential Revision: https://reviews.llvm.org/D50062

llvm-svn: 338676

llvm-svn: 338675

As a part of adding the tiny codemodel, we need to support ldr's with :got:
relocations on them. This seems to be mostly already done, just needs the
relocation type support.

Differential Revision: https://reviews.llvm.org/D50137

llvm-svn: 338673

llvm-svn: 338672

This method has three callers, each of which wanted distinct handling:
1) Sinking into a loop is moving an instruction known to execute before a loop into the loop.  We don't need to worry about introducing a fault at all in this case.
2) Hoisting from a loop into a preheader already duplicated the check in the caller.
3) Sinking from the loop into an exit block was the only true user of the code within the routine.  For the moment, this has just been lifted into the caller, but up next is examining the logic more carefully.  Whitelisting of loads and calls - while consistent with the previous code - is rather suspicious.  Either way, a behavior change is worthy of it's own patch.  

llvm-svn: 338671

llvm-svn: 338670

llvm-svn: 338669

llvm-svn: 338668