llvm-svn: 202732

Breaks the MSVC build.
DataStream.cpp(44): error C2552: 'llvm::Statistic::Value' : non-aggregates cannot be initialized with initializer list

llvm-svn: 202731

With C++11 we finally have a standardized way to specify atomic operations. Use
them to replace the existing custom implemention. Sadly the translation is not
entirely trivial as std::atomic allows more fine-grained control over the
atomicity. I tried to preserve the old semantics as well as possible.

Differential Revision: http://llvm-reviews.chandlerc.com/D2915

llvm-svn: 202730

It's easy to copy unintentionally when using 'auto', particularly inside
range-based for loops.  Best practise is to use 'const&' unless there's
a good reason not to.

llvm-svn: 202729

The current coding standards restrict the use of struct to PODs, but no
one has been following them.  This patch updates the standards to
clarify when structs are dangerous and describe common practice in LLVM.

llvm-svn: 202728

llvm-svn: 202727

llvm-svn: 202726

llvm-svn: 202725

llvm-svn: 202724

llvm-svn: 202723

This seems reasonable and the BackticksWithNoTargetTestCase suggests it
should be this way.

llvm-svn: 202722

llvm-svn: 202721

The shared library generated by autoconf will now be called
libLLVM-$(VERSION_MAJOR).$(VERSION_MINOR).$(VERSION_PATCH)$(VERSION_SUFFIX).so
and a symlink named
libLLVM-$(VERSION_MAJOR).$(VERSION_MINOR)$(VERSION_SUFFIX).so will
also be created in the install directory.

llvm-svn: 202720

Summary:
Previously llvm-config --system-libs would print something like:

$ llvm-config --system-libs

-lz -ltinfo -lrt -ldl -lm

Now we don't emit blank line. Functionality is unchanged otherwise, in
particular llvm-config --libs --system-libs still emits the LLVM libraries
and the system libraries on different lines.

Reviewers: chapuni

Reviewed By: chapuni

CC: llvm-commits

Differential Revision: http://llvm-reviews.chandlerc.com/D2901

llvm-svn: 202719

llvm-svn: 202718

Summary:
Parts of the compiler still believed MSA load/stores have a 16-bit offset when
it is actually 10-bit. Corrected this, and fixed a closely related issue this
uncovered where load/stores with 10-bit and 12-bit offsets (MSA and microMIPS
respectively) could not load/store using offsets from the stack/frame pointer.
They accepted frameindex+offset, but not frameindex by itself.

Reviewers: jacksprat, matheusalmeida

Reviewed By: jacksprat

Differential Revision: http://llvm-reviews.chandlerc.com/D2888

llvm-svn: 202717

This fixes invalid lengths in .debug_aranges on big-endian mips64
(lengths appear to be left-shifted by 32 bits) and in .debug_loc.

Differential Revision: http://llvm-reviews.chandlerc.com/D2517

llvm-svn: 202716

 Fixing a build failure reported by certain buildbots. This will disable jalx instruction for micromips target.

llvm-svn: 202715

llvm-svn: 202714

llvm-svn: 202713

llvm-svn: 202712

llvm-svn: 202711

llvm-svn: 202710

Patch by Konrad Kleine.

llvm-svn: 202709

llvm-svn: 202708

llvm-svn: 202707

This patch implements jalx instruction for Mips architecture.This instruction executes a procedure call within the current 256 MB-aligned region and change the ISA Mode from MIPS32 to microMIPS32 or MIPS16e. Usage samples for assembler and dissasembler are provided as well.

llvm-svn: 202706

This also switches the users in LLVM to ensure this functionality is tested.

llvm-svn: 202705

llvm-svn: 202704

llvm-svn: 202703

a constructor either. Just call the constructor directly. I'll look into
making this work with aggregate initialization some other time (when
I have someone with MSVC 2012 handy to test ideas).

llvm-svn: 202688

operand_values. The first provides a range view over operand Use
objects, and the second provides a range view over the Value*s being
used by those operands.

The naming is "STL-style" rather than "LLVM-style" because we have
historically named iterator methods STL-style, and range methods seem to
have far more in common with their iterator counterparts than with
"normal" APIs. Feel free to bikeshed on this one if you want, I'm happy
to change these around if people feel strongly.

I've switched code in SROA and LCG to exercise these mostly to ensure
they work correctly -- we don't really have an easy way to unittest this
and they're trivial.

llvm-svn: 202687

proposed std::iterator_pair which was in committee suggested to move
toward std::iterator_range. There isn't a formal paper yet, but there
seems little disagreement within the committee at this point so it seems
fine to provide our own version in the llvm namespace so we can easily
build range adaptors for the numerous iterators in LLVM's interfaces.

Note that I'm not really comfortable advocating a crazed range-based
migration just yet. The range stuff is still in a great deal of flux in
C++ and the committee hasn't entirely made up its mind (afaict) about
how it will work. So I'm mostly trying to provide the minimal
functionality needed to make writing easy and convenient range adaptors
for range based for loops easy and convenient. ;]

Subsequent patches will use this across the fundamental IR types, where
there are iterator views.

llvm-svn: 202686

that std::vector constructor.

llvm-svn: 202684

This is used to avoid conflicts with user modules with the same name from different workspaces.

rdar://16042513

llvm-svn: 202683

llvm-svn: 202682

[libclang] Introduce APIs that assist in constructing a simple module.map file for a user framework.

rdar://16092858

llvm-svn: 202681

Determine support for colored output from stdout instead of stderr since that's where the diagnostics go.

llvm-svn: 202680

Allows removing #include's in LLVM while switching to std::unique_ptr.

llvm-svn: 202679

Suggestion by Richard Smith.

llvm-svn: 202678