This compiles with no changes to clang/lld/lldb with MSVC and includes
overloads to various functions which are used by those projects and llvm
which have OwningPtr's as parameters. This should allow out of tree
projects some time to move. There are also no changes to libs/Target,
which should help out of tree targets have time to move, if necessary.

llvm-svn: 203083

DebugInfo: Tag units as having been indexed in GNU pubnames by using a DW_AT_GNU_pubnames of DW_FORM_flag(_present) rather than sec_offsets to the pubnames/types sections

This is consistent with GDB ToT and reduces the number of relocations in
(type and compile) units, substantially reducing relocations and debug
size in fission + type units builds.

llvm-svn: 203082

llvm-svn: 203076

selfhost.

The 'Core.h' C-API header is part of the IR LLVM library. (One might
even argue it should be called IR.h, but that's a separate point.) We
can't include it into a Support header without violating the layering,
and in a way that breaks modules. MemoryBuffer's opaque C type was being
defined in the Core.h C-API header despite being in the Support library,
and thus we ended up with this weird issue.

It turns out that there were other constructs from the Support library
in the Core.h header. This patch lifts all of them into Support.h and
then includes that into Core.h.

The only possible fallout is if someone was including Support.h and
relying on Core.h to be visible for their own uses. Considering the
narrow interface actually provided by the C-API for the Support library,
this seems a very, very unlikely mistake.

llvm-svn: 203071

implementation already lived.

After this commit, the only IR-library headers in include/llvm/* are
ones related to the legacy pass infrastructure that I'm planning to
leave there until the new one is farther along.

The only other headers at the top level are linking and initialization
aids that aren't really libraries but just headers.

llvm-svn: 203069

llvm-svn: 203066

consistent with every other sub-library header in LLVM.

llvm-svn: 203065

obviously coupled to the IR.

llvm-svn: 203064

It ought to be possible to make this truly random access if anyone cares enough.

llvm-svn: 203060

Chandler in review.

llvm-svn: 203058

DebugInfo: Shrink pubnames/pubtypes in the presence of type units by only emitting pub sections for compile units

llvm-svn: 203057

llvm-svn: 203055

The global base register cannot be r0 because it might end up as the first
argument to addi or addis. Fixes PR18316.

I don't have a small stable test case.

llvm-svn: 203054

The iterator is a little complex because we don't want to expose the implementation
details (TrackingVH) of the operand vector to clients.

llvm-svn: 203053

already lives.

llvm-svn: 203046

Like on other targets, we need to zero_extend/truncate i1 args before copying
them to GPRs.

llvm-svn: 203045

pointed to by the attribute, rather than the form as a first
step to determining how to hash the values. No functional change
intended.

llvm-svn: 203044

When copying an i1 value into a GPR for a vaarg call, we need to explicitly
zero-extend the i1 value (otherwise an invalid CRBIT -> GPR copy will be
generated).

llvm-svn: 203041

already lives.

llvm-svn: 203038

are operations that do not access memory but may be sensitive
to floating-point environment changes. LLVM does not attempt
to model FP environment changes, so this was unnecessarily conservative
and was getting on the way of some optimizations, in particular
SLP vectorization.

llvm-svn: 203037

This works by moving the existing code into the DIEValue hierarchy
and using the DwarfDebug pointer off of the AsmPrinter to access
any global information we need.

llvm-svn: 203033

llvm-svn: 203032

for verbose asm.

llvm-svn: 203031

llvm-svn: 203023

llvm-svn: 203020

Thanks to Patrik Hägglund H for noticing it!

llvm-svn: 203019

This enables us to figure out where in the debug_loc section our
locations are so that we can eventually hash them. It also helps
remove some special case code in emission. No functional change.

llvm-svn: 203018

On cores without fpcvt support, we cannot promote int_to_fp i1 operations,
because there is nothing to promote them to. The most straightforward
implementation of this uses a select to choose between the two possible
resulting floating-point values (and that's what is done here).

llvm-svn: 203015

llvm-svn: 203013

llvm-svn: 203011

Provide triple and data layout as well as module names (or empty string) when there's a mismatch.

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

llvm-svn: 203009

Fixes PR19045.

llvm-svn: 203008

Before llvm-mc would print it, but llc was assuming that it would produce
another section changing directive before one was needed. That assumption is
false with inline asm.

Fixes PR19049.

Another option would be to always create the section, but in the asm printer
avoid printing sections changes during initialization. That would work, but
* We do use the fact that llvm-mc prints it in testing. The tests can be changed
  if needed.
* A quick poll on IRC suggest that most developers prefer the implicit .text to
  be printed.

llvm-svn: 203001

When using a //net/ path, we were transforming the trailing / into a '.'
when the path was just the root path and we were iterating backwards.
Forwards iteration and other kinds of root path (C:\, /) were already
correct.

llvm-svn: 202999

llvm-svn: 202997

llvm-svn: 202996

Originally committed in r202985.

llvm-svn: 202992

The build was failing with:

  error C2664: 'std::atomic_int::atomic_int(const std::atomic_int &)' : cannot convert argument 1 from 'int' to 'const std::atomic_int &'

Apparently "std::atomic_int x(0)" doesn't work, but "std::atomic<int> x(0)"
does.

llvm-svn: 202988

llvm-svn: 202985

A version of RefCountedBase that uses std::atomic_int to store its
reference count.

llvm-svn: 202984