We'd like to keep the clang-cl self-host working until we implement
MSVC-compatible RTTI.
Differential Revision: http://llvm-reviews.chandlerc.com/D2930
llvm-svn: 202758
DWARF discriminators are used to distinguish multiple control flow paths
on the same source location. When this happens, instructions across
basic block boundaries will share the same debug location.
This pass detects this situation and creates a new lexical scope to one
of the two instructions. This lexical scope is a child scope of the
original and contains a new discriminator value. This discriminator is
then picked up from MCObjectStreamer::EmitDwarfLocDirective to be
written on the object file.
This fixes http://llvm.org/bugs/show_bug.cgi?id=18270.
llvm-svn: 202752
remove_if that its predicate is adaptable. We don't actually need this,
we can write a generic adapter for any predicate.
This lets us remove some very wrong std::function usages. We should
never be using std::function for predicates to algorithms. This incurs
an *indirect* call overhead for every evaluation of the predicate, and
makes it very hard to inline through.
llvm-svn: 202742
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
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
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
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
The interaction between defaulted operators and move elision isn't
totally obvious, add a unit test so it doesn't break unintentionally.
llvm-svn: 202662
Now that the PowerPC backend can track individual CR bits as first-class
registers, we should also have a way of allocating them for inline asm
statements. Because these registers are only one bit, if an output variable is
implicitly cast to a larger integer size, we'll get an any_extend to that
larger type (this is part of the existing target-independent logic). As a
result, regardless of the size of the output type, only the first bit is
meaningful.
The constraint identifier "wc" has been chosen for this purpose. Although gcc
does not currently support allocating individual CR bits, this identifier
choice has been coordinated with the gcc PowerPC team, and will be marked as
reserved for this purpose in the gcc constraints.md file.
llvm-svn: 202657
This includes instructions that relate to memory access (load/store/GEP), comparison instructions and calls.
Work was done by lama.saba@intel.com.
llvm-svn: 202647
facilitate the nice formatting of lambdas passed there. Suggested by
Chris during review of my lambda additions, and something I strongly
agree with.
llvm-svn: 202622
about a few constructs in C++11 that are worth starting off in
a consistent manner within the codebase.
This will be matched with a change to clang-format's LLVM style which
will switch the options to support C++11 and use these conventions.
llvm-svn: 202620
Aaron Ballman