into their new header subdirectory: include/llvm/IR. This matches the
directory structure of lib, and begins to correct a long standing point
of file layout clutter in LLVM.

There are still more header files to move here, but I wanted to handle
them in separate commits to make tracking what files make sense at each
layer easier.

The only really questionable files here are the target intrinsic
tablegen files. But that's a battle I'd rather not fight today.

I've updated both CMake and Makefile build systems (I think, and my
tests think, but I may have missed something).

I've also re-sorted the includes throughout the project. I'll be
committing updates to Clang, DragonEgg, and Polly momentarily.

llvm-svn: 171366

users over to the new one. No sense maintaining this "compatibility"
layer it seems.

llvm-svn: 171331

Implement the old API in terms of the new one. This simplifies the
implementation on Windows which can now re-use the self_process's once
initialization.

llvm-svn: 171330

This adds AlignedCharArray<Alignment, Size>. A templated struct that contains
a member named buffer of type char[Size] that is aligned to Alignment.

llvm-svn: 171319

The coding style used here is not LLVM's style because this is modeled
after a Boost interface and thus done in the style of a candidate C++
standard library interface. I'll probably end up proposing it as
a standard C++ library if it proves to be reasonably portable and
useful.

This is just the most basic parts of the interface -- getting the
process ID out of it. However, it helps sketch out some of the boiler
plate such as the base class, derived class, shared code, and static
factory function. It also introduces a unittest so that I can
incrementally ensure this stuff works.

However, I've not even compiled this code for Windows yet. I'll try to
fix any Windows fallout from the bots, and if I can't fix it I'll revert
and get someone on Windows to help out. There isn't a lot more that is
mandatory, so soon I'll switch to just stubbing out the Windows side and
get Michael Spencer to help with implementation as he can test it
directly.

llvm-svn: 171289

llvm-svn: 170376

llvm-svn: 170369

llvm-svn: 170035

llvm-svn: 170033

structures to and from YAML using traits.  The first client will
be the test suite of lld.  The documentation will show up at:

   http://llvm.org/docs/YamlIO.html

llvm-svn: 170019

MF_READ and MF_WRITE are set.

llvm-svn: 169439

llvm-svn: 169250

llvm-svn: 169167

Rationale:
1) This was the name in the comment block. ;]
2) It matches Clang's __has_feature naming convention.
3) It matches other compiler-feature-test conventions.

Sorry for the noise. =]

I've also switch the comment block to use a \brief tag and not duplicate
the name.

llvm-svn: 168996

appropriate unit tests. This change in itself is not expected to
affect any functionality at this point, but it will serve as a
stepping stone to improve FileCheck's variable matching capabilities.

Luckily, our regex implementation already supports backreferences,
although a bit of hacking is required to enable it. It supports both
Basic Regular Expressions (BREs) and Extended Regular Expressions
(EREs), without supporting backrefs for EREs, following POSIX strictly
in this respect. And EREs is what we actually use (rightly). This is
contrary to many implementations (including the default on Linux) of
POSIX regexes, that do allow backrefs in EREs.

Adding backref support to our EREs is a very simple change in the
regcomp parsing code. I fail to think of significant cases where it
would clash with existing things, and can bring more versatility to
the regexes we write. There's always the danger of a backref in a
specially crafted regex causing exponential matching times, but since
we mainly use them for testing purposes I don't think it's a big
problem. [it can also be placed behind a flag specific to FileCheck,
if needed].

For more details, see:

* http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-November/055840.html
* http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20121126/156878.html

llvm-svn: 168802

The rationale is to get YAML filenames in diagnostics from
yaml::Stream::printError -- currently the filename is hard-coded as
"YAML" because there's no buffer information available.

Patch by Kim Gräsman!

llvm-svn: 168341

llvm-svn: 168253

due to ambiguity' warning.

llvm-svn: 168251

llvm-svn: 167968

ICC refuses to compile a class in an anonymous namespace if some functions
aren't defined. Fixes PR13477.

llvm-svn: 167676

Additionally, all such cases are handled with no dynamic check.

All `classof()` of the form

    class Foo {
      [...]
      static bool classof(const Bar *) { return true; }
      [...]
    }

where Foo is an ancestor of Bar are no longer necessary.
Don't write them!

Note: The exact test is `is_base_of<Foo, Bar>`, which is non-strict, so
that Foo is considered an ancestor of itself.

This leads to the following rule of thumb for LLVM-style RTTI:

    The argument type of `classof()` should be a strict ancestor.

For more information about implementing LLVM-style RTTI, see
docs/HowToSetUpLLVMStyleRTTI.rst

llvm-svn: 165765

Patch by Daniel Malea.

llvm-svn: 165246

This patch adds memory support functions which will later be used to implement section-specific protection handling in MCJIT.

llvm-svn: 164249

llvm-svn: 163950

 - The current_pos function is supposed to return all the written bytes, not the
   current position of the underlying stream.
 - This caused tell() to be broken whenever the underlying stream had buffered
   content.

llvm-svn: 163948

Review by Chandler Carruth.

llvm-svn: 163944

llvm-svn: 162310

llvm-svn: 162201

templated union at the request of Richard Smith. This makes it
substantially easier to type. =]

llvm-svn: 162072

llvm-svn: 161979

llvm-svn: 161976

llvm-svn: 161751

Since the llvm::sys::fs::map_file_pages() support function it relies on
is not yet implemented on Windows, the unit tests for FileOutputBuffer 
are currently conditionalized to run only on unix.

llvm-svn: 161099

llvm-svn: 161085

llvm-svn: 160643

llvm-svn: 160317

Make it always return APInts with the same bitwidth for the same ConstantRange bitwidth to simply clients

llvm-svn: 160294

the original move of IRBuilder.

llvm-svn: 160249

the move of *Builder classes into the Core library.

No uses of this builder in Clang or DragonEgg I could find.

If there is a desire to have an IR-building-support library that
contains all of these builders, that can be easily added, but currently
it seems likely that these add no real overhead to VMCore.

llvm-svn: 160243

IRBuilder, DIBuilder, etc.

This is the proper layering as MDBuilder can't be used (or implemented)
without the Core Metadata representation.

Patches to Clang and Dragonegg coming up.

llvm-svn: 160237