Added D20528 implementations as well as existing x86 intrinsics versions

llvm-svn: 270494

Reviewers: spyffe

Subscribers: lldb-commits

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

llvm-svn: 270493

Before r269750 we did the comparisons in this loop in signed ints so
that it DTRT when MinCSFrameIndex was 0. This was changed because it's
now possible for MinCSFrameIndex to be UINT_MAX, but that introduced a
bug when we were comparing `>= 0` - this is tautological in unsigned.

Rework the comparisons here to avoid issues with unsigned wrapping.

No test. I couldn't find a way to get any of the StackGrowsUp in-tree
targets to reach the code that sets MinCSFrameIndex.

llvm-svn: 270492

to llvm-objdump. This section is created with -fembed-bitcode option.

This requires the use of libxar and the Cmake and lit support were crafted by
Chris Bieneman!

rdar://26202242

llvm-svn: 270491

llvm-svn: 270490

llvm-svn: 270489

One of the things slowing us down is that ItaniumABILanguageRuntime class doesn't cache vtable to types in a map. This causes us, on every step, for every variable, to read the first pointer in a C++ type that could be dynamic and lookup the symbol, possibly in every symbol file (some symbols files on Darwin can end up having thousands of .o files when using DWARF in .o files, so thousands of .o files are searched each time). 

This fix caches lldb_private::Address (the resolved vtable symbol address in section + offset format) to TypeAndOrName instances inside the one ItaniumABILanguageRuntime in a process. This allows caching of dynamic types and stops us from always doing deep searches in each file.

<rdar://problem/18890778>

llvm-svn: 270488

This is a work in progress - the chapter text is incomplete, though
the example code compiles and runs.

Feedback and patches are, as usual, most welcome.

llvm-svn: 270487

They were accidentally using the 32-bit load/store instruction for
8/16-bit operations, due to incorrect patterns

(8/16-bit cmpxchg and atomicrmw will be fixed in subsequent changes)

llvm-svn: 270486

This effectively revers commit r270389 and re-lands r270106, but it's
almost a rewrite.

The behavior change in r270106 was that we could no longer assume that
each LF_FUNC_ID record got its own type index. This patch adds a map
from DINode* to TypeIndex, so we can stop making that assumption.

This change also emits padding bytes between type records similar to the
way MSVC does. The size of the type record includes the padding bytes.

llvm-svn: 270485

Summary:
This lets us emit e.g. sin.approx.f32.  See
http://docs.nvidia.com/cuda/parallel-thread-execution/#floating-point-instructions-sin

Reviewers: rnk

Subscribers: tra, cfe-commits

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

llvm-svn: 270484

 o make warning message more meaningful to users.
 o add suggestion to fix the problem
 o limit the max number of output.

llvm-svn: 270483

map to the redecl context for both decls, not just one of them, and to properly
check that the decl contexts are equivalent.

llvm-svn: 270482

to query interfaces argument; NFC

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

llvm-svn: 270481

llvm-svn: 270480

When an aggregate contains an opaque type its size cannot be
determined. This triggers an "Invalid GetElementPtrInst indices for type" assert
in function checkGEPType. The fix suppresses the conversion in this case.

http://reviews.llvm.org/D20319

llvm-svn: 270479

Summary:
This patch turns on LoopUnrollAnalyzer by default. To mitigate compile
time regressions, I chose very conservative thresholds for now. Later we
can make them more aggressive, but it might require being smarter in
which loops we're optimizing. E.g. currently the biggest issue is that
with more agressive thresholds we unroll many cold loops, which
increases compile time for no performance benefit (performance of those
loops is improved, but it doesn't matter since they are cold).

Test results for compile time(using 4 samples to reduce noise):
```
MultiSource/Benchmarks/VersaBench/ecbdes/ecbdes 5.19%
SingleSource/Benchmarks/Polybench/medley/reg_detect/reg_detect  4.19%
MultiSource/Benchmarks/FreeBench/fourinarow/fourinarow  3.39%
MultiSource/Applications/JM/lencod/lencod 1.47%
MultiSource/Benchmarks/Fhourstones-3_1/fhourstones3_1 -6.06%
```

I didn't see any performance changes in the testsuite, but it improves
some internal tests.

Reviewers: hfinkel, chandlerc

Subscribers: llvm-commits, mzolotukhin

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

llvm-svn: 270478

Summary:
MBBs don't necessarily have a name (in my experience, they almost never
do), in which case this logging is quite unhelpful.  The number seems to
work well.

Reviewers: iteratee

Subscribers: llvm-commits

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

llvm-svn: 270477

This makes it easier to use Xcode revision diffing tools on them.

llvm-svn: 270476

This will pave the way to introduce a full fledged symbol visitor
similar to how we have a type visitor, thus allowing the same
dumping code to be used in llvm-readobj and llvm-pdbdump.

Differential Revision: http://reviews.llvm.org/D20384
Reviewed By: rnk

llvm-svn: 270475

m_decl_objects is problematic because it assumes that each VarDecl has a unique
variable associated with it.  This is not the case in inline contexts.

Also the information in this map can be reconstructed very easily without
maintaining the map.  The rest of the testsuite passes with this cange, and I've
added a testcase covering the inline contexts affected by this.

<rdar://problem/26278502>

llvm-svn: 270474

llvm-svn: 270473

llvm-svn: 270472

The dead declarations made MSVC to warn on explicit template
instantiations of the classes.

llvm-svn: 270471

llvm-svn: 270470

llvm-svn: 270469

Most of this is modifications to check for differences before updating data
fields in team struct. There is also some rearrangement of the team struct.

Patch by Diego Caballero

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

llvm-svn: 270468

llvm-svn: 270467

llvm-svn: 270466

llvm-svn: 270465

These changes allow testing on Windows using clang.exe.
There are two main changes:
1. Only link to -lm when it actually exists on the system
2. Create basic versions of pthread_create() and pthread_join() for windows.
   They are not POSIX compliant by any stretch but will allow any existing
   and future tests to use pthread_create() and pthread_join() for testing
   interactions of libomp with os threads.

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

llvm-svn: 270464

Use the more specific LiveInterval::removeSegment instead of
LiveInterval::shrinkToUses when we know the specific range that's
being removed.

llvm-svn: 270463

Now that the string pool is referential rather than maintaining its own
copy of string data, compressed sections (well, technically only the
debug_str section*) need to be preserved for the lifetime of the pool to
match.

* I'm not currently optimizing for memory footprint with compressed
  input - the major memory limit I'm hitting is on dwp+dwp merge steps
  and we aren't currently compressing contents in dwp files, just in the
  .dwo inputs.

llvm-svn: 270462

Add two tests which show our error handling behavior for invalid
parameters in the layout_version and empty_bases attributes.

Amend our documentation to make it more clear that
__declspec(empty_bases) and __declspec(layout_version) can only apply to
classes, structs, and unions.

llvm-svn: 270461

There is flakiness somewhere in the core infrastructure on Windows,
so to get the buildbot reliably green we need to mark all tests
as flaky.

llvm-svn: 270460

llvm-svn: 270459

MSVC now supports the __is_assignable type trait intrinsic,
to enable easier and more efficient implementation of the
Standard Library's is_assignable trait.
As of Visual Studio 2015 Update 3, the VC Standard Library
implementation uses the new intrinsic unconditionally.

The implementation is pretty straightforward due to the previously
existing is_nothrow_assignable and is_trivially_assignable.
We handle __is_assignable via the same code as the other two except
that we skip the extra checks for nothrow or triviality.

Patch by Dave Bartolomeo!

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

llvm-svn: 270458

The layout_version attribute is pretty straightforward: use the layout
rules from version XYZ of MSVC when used like
struct __declspec(layout_version(XYZ)) S {};

The empty_bases attribute is more interesting.  It tries to get the C++
empty base optimization to fire more often by tweaking the MSVC ABI
rules in subtle ways:
1. Disable the leading and trailing zero-sized object flags if a class
   is marked __declspec(empty_bases) and is empty.

   This means that given:
   struct __declspec(empty_bases) A {};
   struct __declspec(empty_bases) B {};
   struct C : A, B {};

   'C' will have size 1 and nvsize 0 despite not being annotated
   __declspec(empty_bases).

2. When laying out virtual or non-virtual bases, disable the injection
   of padding between classes if the most derived class is marked
   __declspec(empty_bases).

   This means that given:
   struct A {};
   struct B {};
   struct __declspec(empty_bases) C : A, B {};

   'C' will have size 1 and nvsize 0.

3. When calculating the offset of a non-virtual base, choose offset zero
   if the most derived class is marked __declspec(empty_bases) and the
   base is empty _and_ has an nvsize of 0.

   Because of the ABI rules, this does not mean that empty bases
   reliably get placed at offset 0!

   For example:
   struct A {};
   struct B {};
   struct __declspec(empty_bases) C : A, B { virtual ~C(); };

   'C' will be pointer sized to account for the vfptr at offset 0.
   'A' and 'B' will _not_ be at offset 0 despite being empty!
   Instead, they will be located right after the vfptr.

   This occurs due to the interaction betweeen non-virtual base layout
   and virtual function pointer injection: injection occurs after the
   nv-bases and shifts them down by the size of a pointer.

llvm-svn: 270457

SBValue::CreateValueFromData didn’t check whether the SBType passed into it is in fact a valid type - this can lead to LLDB crashing upon access

Committing on behalf of Sebastian Theophil

llvm-svn: 270456

Previously, mergeable section's constructors did more than just
setting member variables; it split section contents into small
pieces. It is not always computationally cheap task because if
the section is a mergeable string section, it needs to scan the
entire section to split them by NUL characters.

If a section would be thrown away by GC, that cost ended up
being a waste of time. It is going to be larger problem if the
section is compressed -- the whole time to uncompress it and
split it up is going to be a waste.

Luckily, we can defer section splitting after GC. We just have
to remember which offsets are in use during GC and apply that later.
This patch implements it.

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

llvm-svn: 270455