Use the appropriate helper instead.

llvm-svn: 254990

llvm-svn: 254989

It's strange to duplicate the logic for emitting FP values into
emitGlobalConstantDataSequential, and it's even stranger that we end
up printing the verbose assembly comments differently between the two
paths. Just call into emitGlobalConstantFP rather than crudely
duplicating its logic.

llvm-svn: 254988

llvm-svn: 254987

llvm-svn: 254986

llvm-svn: 254985

handle more than just C.

llvm-svn: 254984

llvm-svn: 254983

This moves all the global variables into a separate module called
`configuration`.  This has a number of advantages:

1. Configuration data is centrally maintained so it's easy to get
   a high level overview of what configuration data the test suite
   makes use of.
2. The method of sharing configuration data among different parts
   of the test suite becomes standardized.  Previously we would
   put some things into the `lldb` module, some things into the
   `lldbtest_config` module, and some things would not get shared.
   Now everything is shared through one module and is available to
   the entire test suite.
3. It opens the door to moving some of the initialization code into
   the `configuration` module, simplifying the implementation of
   `dotest.py`.

There are a few stragglers that didn't get converted over to using
the `configuration` module in this patch, because it would have grown
the size of the patch unnecessarily.  This includes everything
currently in the `lldbtest_config` module, as well as the
`lldb.remote_platform` variable.  We can address these in the future.

llvm-svn: 254982

When attempting to map a source into a given level of macro expansion,
this code was ignoring the possibility that the start and end of the
range might take wildly different paths through the tree of macro
expansions. It was assuming that the begin spelling location would
always precede the end spelling location, which is false. A macro can
easily transpose its arguments.

This also fixes a related issue where there are extra macro arguments
between the begin location and the end location. In this situation, we
now highlight the entire macro invocation.

Pair programmed with Richard Smith.

Fixes PR12818.

llvm-svn: 254981

It was previously reverted due to issues that showed up only on linux. I was able to reproduce these issues and fix the underlying cause.

So this is the same patch as 254476 with the following two fixes:
- Fix not trying to complete classes that don't have external sources
- Fix ClangASTSource::CompleteType() to check the decl context of types that it finds by basename to ensure we don't complete a type "S" with a type like "std::S". Before this fix ClangASTSource::CompleteType() would accept _any_ type that had a matching basename and copy it into the other type.

<rdar://problem/22992457>

llvm-svn: 254980

This cleans up dotest.py and is a pre-step for getting
the test inferior runner to send post-inferior run events
to the events collector, as this code needs to be accessed
from within dosep.py.

llvm-svn: 254979

rdar://9001553

llvm-svn: 254978

Summary:
Also add a stricter post-condition for IndVarSimplify.

Fixes PR25578.  Test case by Michael Zolotukhin.

Reviewers: hfinkel, atrick, mzolotukhin

Subscribers: llvm-commits

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

llvm-svn: 254977

Summary:
(Note: the problematic invocation of hoistIVInc that caused PR24804 came
from IndVarSimplify, not from SCEVExpander itself)

Fixes PR24804.  Test case by David Majnemer.

Reviewers: hfinkel, majnemer, atrick, mzolotukhin

Subscribers: llvm-commits

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

llvm-svn: 254976

Will be used in a upcoming patch.

llvm-svn: 254975

We were using unneccessarily large initial sizes for these SmallVectors.  This was wasting around 50kb of memory for the O3 pipeline, even after the uniquing changes.  We're still using around 20kb which is a bit much, but it's definitely better.  This is about a 6% improvement in total O3 memory usage.

Note: The raw data on structure size which were used to pick these thresholds can be found in the review thread.

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

llvm-svn: 254974

llvm-svn: 254973

llvm-svn: 254972

llvm-svn: 254971

llvm-svn: 254968

llvm-svn: 254967

llvm-svn: 254966

A manipulation (in this case, mkdir) can make slack between creating and touching %t.older/evenlen.

I would make this rewrote with python if this were still unstable.

llvm-svn: 254965

Based on patch by Pete Cooper.

llvm-svn: 254964

llvm-svn: 254963

When a C++ lambda captures a variable-length array, it creates a capture
field to store the size of the array. The initialization expression for this
capture is null, which led the analyzer to crash when initializing the field.
To avoid this, use the size expression from the VLA type to determine the
initialization value.

rdar://problem/23748072

llvm-svn: 254962

llvm-svn: 254961

llvm-svn: 254960

llvm-svn: 254959

llvm-svn: 254958

254950 ended up being not NFC.  The previous code was overriding the flags for whether an instruction read or wrote memory using the target specific flags returned via TTI.  I'd missed this in my refactoring.  Since I mistakenly built only x86 and didn't notice the number of unsupported tests, I didn't catch that before the original checkin.

This raises an interesting issue though.  Given we have function attributes (i.e. readonly, readnone, argmemonly) which describe the aliasing of intrinsics, why does TTI have this information overriding the instruction definition at all?  I see no reason for this, but decided to preserve existing behavior for the moment.  The root issue might be that we don't have a "writeonly" attribute.

Original commit message:
[EarlyCSE] Simplify and invert ParseMemoryInst [NFCI]

Restructure ParseMemoryInst - which was introduced to abstract over target specific load and stores instructions - to just query the underlying instructions. In theory, this could be slightly slower than caching the results, but in practice, it's very unlikely to be measurable.

The simple query scheme makes it far easier to understand, and much easier to extend with new queries. Given I'm about to need to add new query types, doing the cleanup first seemed worthwhile.

Do we still believe the target specific intrinsic handling is worthwhile in EarlyCSE? It adds quite a bit of complexity and makes the code harder to read. Being able to delete the abstraction entirely would be wonderful.

llvm-svn: 254957

This is supposed to force-link the Interpreter, by inserting a dead
call to LLVMLinkInInterpreter().
Since it is actually an empty function, there is no reason for the
call to be dead.

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 254956

Check that TSan runtime doesn't contain compiler-inserted calls
to memset/memmove functions.

In future, we may consider moving this test to test/sanitizer_common,
as we don't want to have compiler-inserted memcpy/memmove calls in
any sanitizer runtime.

llvm-svn: 254955

It's causing test failures on AArch64.  Due to a bad build config on my part, I apparently wasn't running the tests I thought I was.

llvm-svn: 254954

llvm-svn: 254953

llvm-svn: 254952

Restructure ParseMemoryInst - which was introduced to abstract over target specific load and stores instructions - to just query the underlying instructions. In theory, this could be slightly slower than caching the results, but in practice, it's very unlikely to be measurable.

The simple query scheme makes it far easier to understand, and much easier to extend with new queries. Given I'm about to need to add new query types, doing the cleanup first seemed worthwhile.

Do we still believe the target specific intrinsic handling is worthwhile in EarlyCSE? It adds quite a bit of complexity and makes the code harder to read. Being able to delete the abstraction entirely would be wonderful.

llvm-svn: 254950

Summary: NetBSD soon will reuse this feature while running tests.

Reviewers: emaste, tfiala, clayborg

Subscribers: lldb-commits, joerg

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

llvm-svn: 254949

Summary:
Add new functions:

  - expectedFailureNetBSD()
  - expectedFlakeyNetBSD()
  - skipIfNetBSD()

Add new NetBSD entry in:

  - getPlatform()
  - getHostPlatform()

Assume that libc++ is installed and use the GNU toolchain

Reviewers: joerg, emaste, tfiala, clayborg

Subscribers: lldb-commits

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

llvm-svn: 254948