Commit Graph

49 Commits

Author SHA1 Message Date
Rafael Espindola
ada5f24b5f The leak detector is dead, long live asan and valgrind.
In resent times asan and valgrind have found way more memory management bugs
in llvm than the special purpose leak detector.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@224703 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-22 13:00:36 +00:00
JF Bastien
544f63e84a Random Number Generator Refactoring (removing from Module)
This patch removes the RNG from Module. Passes should instead create a new RNG for their use as needed.

Patch by Stephen Crane @rinon.

Differential revision: http://reviews.llvm.org/D4377

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@224444 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-17 18:12:10 +00:00
Duncan P. N. Exon Smith
dad20b2ae2 IR: Split Metadata from Value
Split `Metadata` away from the `Value` class hierarchy, as part of
PR21532.  Assembly and bitcode changes are in the wings, but this is the
bulk of the change for the IR C++ API.

I have a follow-up patch prepared for `clang`.  If this breaks other
sub-projects, I apologize in advance :(.  Help me compile it on Darwin
I'll try to fix it.  FWIW, the errors should be easy to fix, so it may
be simpler to just fix it yourself.

This breaks the build for all metadata-related code that's out-of-tree.
Rest assured the transition is mechanical and the compiler should catch
almost all of the problems.

Here's a quick guide for updating your code:

  - `Metadata` is the root of a class hierarchy with three main classes:
    `MDNode`, `MDString`, and `ValueAsMetadata`.  It is distinct from
    the `Value` class hierarchy.  It is typeless -- i.e., instances do
    *not* have a `Type`.

  - `MDNode`'s operands are all `Metadata *` (instead of `Value *`).

  - `TrackingVH<MDNode>` and `WeakVH` referring to metadata can be
    replaced with `TrackingMDNodeRef` and `TrackingMDRef`, respectively.

    If you're referring solely to resolved `MDNode`s -- post graph
    construction -- just use `MDNode*`.

  - `MDNode` (and the rest of `Metadata`) have only limited support for
    `replaceAllUsesWith()`.

    As long as an `MDNode` is pointing at a forward declaration -- the
    result of `MDNode::getTemporary()` -- it maintains a side map of its
    uses and can RAUW itself.  Once the forward declarations are fully
    resolved RAUW support is dropped on the ground.  This means that
    uniquing collisions on changing operands cause nodes to become
    "distinct".  (This already happened fairly commonly, whenever an
    operand went to null.)

    If you're constructing complex (non self-reference) `MDNode` cycles,
    you need to call `MDNode::resolveCycles()` on each node (or on a
    top-level node that somehow references all of the nodes).  Also,
    don't do that.  Metadata cycles (and the RAUW machinery needed to
    construct them) are expensive.

  - An `MDNode` can only refer to a `Constant` through a bridge called
    `ConstantAsMetadata` (one of the subclasses of `ValueAsMetadata`).

    As a side effect, accessing an operand of an `MDNode` that is known
    to be, e.g., `ConstantInt`, takes three steps: first, cast from
    `Metadata` to `ConstantAsMetadata`; second, extract the `Constant`;
    third, cast down to `ConstantInt`.

    The eventual goal is to introduce `MDInt`/`MDFloat`/etc. and have
    metadata schema owners transition away from using `Constant`s when
    the type isn't important (and they don't care about referring to
    `GlobalValue`s).

    In the meantime, I've added transitional API to the `mdconst`
    namespace that matches semantics with the old code, in order to
    avoid adding the error-prone three-step equivalent to every call
    site.  If your old code was:

        MDNode *N = foo();
        bar(isa             <ConstantInt>(N->getOperand(0)));
        baz(cast            <ConstantInt>(N->getOperand(1)));
        bak(cast_or_null    <ConstantInt>(N->getOperand(2)));
        bat(dyn_cast        <ConstantInt>(N->getOperand(3)));
        bay(dyn_cast_or_null<ConstantInt>(N->getOperand(4)));

    you can trivially match its semantics with:

        MDNode *N = foo();
        bar(mdconst::hasa               <ConstantInt>(N->getOperand(0)));
        baz(mdconst::extract            <ConstantInt>(N->getOperand(1)));
        bak(mdconst::extract_or_null    <ConstantInt>(N->getOperand(2)));
        bat(mdconst::dyn_extract        <ConstantInt>(N->getOperand(3)));
        bay(mdconst::dyn_extract_or_null<ConstantInt>(N->getOperand(4)));

    and when you transition your metadata schema to `MDInt`:

        MDNode *N = foo();
        bar(isa             <MDInt>(N->getOperand(0)));
        baz(cast            <MDInt>(N->getOperand(1)));
        bak(cast_or_null    <MDInt>(N->getOperand(2)));
        bat(dyn_cast        <MDInt>(N->getOperand(3)));
        bay(dyn_cast_or_null<MDInt>(N->getOperand(4)));

  - A `CallInst` -- specifically, intrinsic instructions -- can refer to
    metadata through a bridge called `MetadataAsValue`.  This is a
    subclass of `Value` where `getType()->isMetadataTy()`.

    `MetadataAsValue` is the *only* class that can legally refer to a
    `LocalAsMetadata`, which is a bridged form of non-`Constant` values
    like `Argument` and `Instruction`.  It can also refer to any other
    `Metadata` subclass.

(I'll break all your testcases in a follow-up commit, when I propagate
this change to assembly.)

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223802 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-09 18:38:53 +00:00
Rafael Espindola
eee41dbb65 Ask the module for its the identified types.
When lazy reading a module, the types used in a function will not be visible to
a TypeFinder until the body is read.

This patch fixes that by asking the module for its identified struct types.
If a materializer is present, the module asks it. If not, it uses a TypeFinder.

This fixes pr21374.

I will be the first to say that this is ugly, but it was the best I could find.

Some of the options I looked at:

* Asking the LLVMContext. This could be made to work for gold, but not currently
  for ld64. ld64 will load multiple modules into a single context before merging
  them. This causes us to see types from future merges. Unfortunately,
  MappedTypes is not just a cache when it comes to opaque types. Once the
  mapping has been made, we have to remember it for as long as the key may
  be used. This would mean moving MappedTypes to the Linker class and having
  to drop the Linker::LinkModules static methods, which are visible from C.

* Adding an option to ignore function bodies in the TypeFinder. This would
  fix the PR by picking the worst result. It would work, but unfortunately
  we are currently quite dependent on the upfront type merging. I will
  try to reduce our dependency, but it is not clear that we will be able
  to get rid of it for now.

The only clean solution I could think of is making the Module own the types.
This would have other advantages, but it is a much bigger change. I will
propose it, but it is nice to have this fixed while that is discussed.

With the gold plugin, this patch takes the number of types in the LTO clang
binary from 52817 to 49669.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223215 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-03 07:18:23 +00:00
David Blaikie
1d4f28c6bc Remove StringMap::GetOrCreateValue in favor of StringMap::insert
Having two ways to do this doesn't seem terribly helpful and
consistently using the insert version (which we already has) seems like
it'll make the code easier to understand to anyone working with standard
data structures. (I also updated many references to the Entry's
key and value to use first() and second instead of getKey{Data,Length,}
and get/setValue - for similar consistency)

Also removes the GetOrCreateValue functions so there's less surface area
to StringMap to fix/improve/change/accommodate move semantics, etc.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@222319 91177308-0d34-0410-b5e6-96231b3b80d8
2014-11-19 05:49:42 +00:00
Duncan P. N. Exon Smith
5bf8ade9d0 Revert "IR: MDNode => Value"
Instead, we're going to separate metadata from the Value hierarchy.  See
PR21532.

This reverts commit r221375.
This reverts commit r221373.
This reverts commit r221359.
This reverts commit r221167.
This reverts commit r221027.
This reverts commit r221024.
This reverts commit r221023.
This reverts commit r220995.
This reverts commit r220994.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221711 91177308-0d34-0410-b5e6-96231b3b80d8
2014-11-11 21:30:22 +00:00
Justin Hibbits
893f22f882 Add Position-independent Code model Module API.
Summary:
This makes PIC levels a Module flag attribute, which can be queried by the
backend.  The flag is named `PIC Level`, and can have a value of:

  0 - Backend-default
  1 - Small-model (-fpic)
  2 - Large-model (-fPIC)

These match the `-pic-level' command line argument for clang, and the value of the
preprocessor macro `__PIC__'.

Test Plan:
New flags tests specific for the 'PIC Level' module flag.
Tests to be added as part of a future commit for PowerPC, which will use this new API.

Reviewers: rafael, echristo

Reviewed By: rafael, echristo

Subscribers: rafael, llvm-commits

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221510 91177308-0d34-0410-b5e6-96231b3b80d8
2014-11-07 04:46:10 +00:00
Duncan P. N. Exon Smith
bad06b13ba IR: MDNode => Value: NamedMDNode::getOperator()
Change `NamedMDNode::getOperator()` from returning `MDNode *` to
returning `Value *`.  To reduce boilerplate at some call sites, add a
`getOperatorAsMDNode()` for named metadata that's expected to only
return `MDNode` -- for now, that's everything, but debug node named
metadata (such as llvm.dbg.cu and llvm.dbg.sp) will soon change.  This
is part of PR21433.

Note that there's a follow-up patch to clang for the API change.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221375 91177308-0d34-0410-b5e6-96231b3b80d8
2014-11-05 18:16:03 +00:00
Rafael Espindola
c498284e46 Modernize the error handling of the Materialize function.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220600 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-24 22:50:48 +00:00
Rafael Espindola
68b02dcd54 Don't ever call materializeAllPermanently during LTO.
To do this, change the representation of lazy loaded functions.

The previous representation cannot differentiate between a function whose body
has been removed and one whose body hasn't been read from the .bc file. That
means that in order to drop a function, the entire body had to be read.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220580 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-24 18:13:04 +00:00
Alexey Samsonov
e769dc39fd Be more careful in parsing Module::ModFlagBehavior value
to make sure we don't do invalid load of an enum. Share the
conversion code between llvm::Module implementation and the
verifier.

This bug was reported by UBSan.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217395 91177308-0d34-0410-b5e6-96231b3b80d8
2014-09-08 19:16:28 +00:00
Rafael Espindola
2292996e1a Pass a MemoryBufferRef when we can avoid taking ownership.
The attached patch simplifies a few interfaces that don't need to take
ownership of a buffer.

For example, both parseAssembly and parseBitcodeFile will parse the
entire buffer before returning. There is no need to take ownership.

Using a MemoryBufferRef makes it obvious in the type signature that
there is no ownership transfer.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216488 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-26 21:49:01 +00:00
David Majnemer
8234268c7e IR: cleanup Module::dropReferences
This replaces some old-style loops with range-based for.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@212278 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-03 16:12:55 +00:00
David Majnemer
c8a1169c93 IR: Add COMDATs to the IR
This new IR facility allows us to represent the object-file semantic of
a COMDAT group.

COMDATs allow us to tie together sections and make the inclusion of one
dependent on another. This is required to implement features like MS
ABI VFTables and optimizing away certain kinds of initialization in C++.

This functionality is only representable in COFF and ELF, Mach-O has no
similar mechanism.

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211920 91177308-0d34-0410-b5e6-96231b3b80d8
2014-06-27 18:19:56 +00:00
JF Bastien
b4840d7a4d Random Number Generator (llvm)
Provides an abstraction for a random number generator (RNG) that produces a stream of pseudo-random numbers.
The current implementation uses C++11 facilities and is therefore not cryptographically secure.

The RNG is salted with the text of the current command line invocation.
In addition, a user may specify a seed (reproducible builds).

In clang, the seed can be set via

-frandom-seed=X
In the back end, the seed can be set via

-rng-seed=X
This is the llvm part of the patch.
clang part: D3391

URL: http://reviews.llvm.org/D3390
Author: yln

I'm landing this for the second time, it broke Windows bots the first time around.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211705 91177308-0d34-0410-b5e6-96231b3b80d8
2014-06-25 15:21:42 +00:00
Rafael Espindola
1f659329b6 Make ObjectFile and BitcodeReader always own the MemoryBuffer.
This allows us to just use a std::unique_ptr to store the pointer to the buffer.
The flip side is that they have to support releasing the buffer back to the
caller.

Overall this looks like a more efficient and less brittle api.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211542 91177308-0d34-0410-b5e6-96231b3b80d8
2014-06-23 21:53:12 +00:00
JF Bastien
02b4e6e7ab Revert "Random Number Generator (llvm)"
This reverts commit cccba093090d127e0b6d17473b14c264c14c5259.

It causes build breakage.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211146 91177308-0d34-0410-b5e6-96231b3b80d8
2014-06-18 06:33:23 +00:00
JF Bastien
1d04a2324c Random Number Generator (llvm)
Summary:
Provides an abstraction for a random number generator (RNG) that produces a stream of pseudo-random numbers.
The current implementation uses C++11 facilities and is therefore not cryptographically secure.

The RNG is salted with the text of the current command line invocation.
In addition, a user may specify a seed (reproducible builds).

In clang, the seed can be set via
  -frandom-seed=X
In the back end, the seed can be set via
  -rng-seed=X

This is the llvm part of the patch.
clang part: D3391

Reviewers: ahomescu, rinon, nicholas, jfb

Reviewed By: jfb

Subscribers: jfb, perl

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211145 91177308-0d34-0410-b5e6-96231b3b80d8
2014-06-18 06:23:25 +00:00
Rafael Espindola
4e2b922131 Remove 'using std::errro_code' from lib.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210871 91177308-0d34-0410-b5e6-96231b3b80d8
2014-06-13 02:24:39 +00:00
Rafael Espindola
5c792faa0e Don't use 'using std::error_code' in include/llvm.
This should make sure that most new uses use the std prefix.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210835 91177308-0d34-0410-b5e6-96231b3b80d8
2014-06-12 21:46:39 +00:00
Rafael Espindola
1bab2d5399 Use error_code() instead of error_code::succes()
There is no std::error_code::success, so this removes much of the noise
in transitioning to std::error_code.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209952 91177308-0d34-0410-b5e6-96231b3b80d8
2014-05-31 01:37:45 +00:00
Diego Novillo
0a0d620db3 Fix bug 19437 - Only add discriminators for DWARF 4 and above.
Summary:
This prevents the discriminator generation pass from triggering if
the DWARF version being used in the module is prior to 4.

Reviewers: echristo, dblaikie

CC: llvm-commits

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206507 91177308-0d34-0410-b5e6-96231b3b80d8
2014-04-17 22:33:50 +00:00
Craig Topper
ec0f0bc6af [C++11] More 'nullptr' conversion or in some cases just using a boolean check instead of comparing to nullptr.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@205831 91177308-0d34-0410-b5e6-96231b3b80d8
2014-04-09 06:08:46 +00:00
Duncan P. N. Exon Smith
f5d17528ee Module: Don't rename in getOrInsertFunction()
During LTO, user-supplied definitions of C library functions often
exist.  -instcombine uses Module::getOrInsertFunction() to get a handle
on library functions (e.g., @puts, when optimizing @printf).

Previously, Module::getOrInsertFunction() would rename any matching
functions with local linkage, and create a new declaration.  In LTO,
this is the opposite of desired behaviour, as it skips by the
user-supplied version of the library function and creates a new
undefined reference which the linker often cannot resolve.

After some discussing with Rafael on the list, it looks like it's
undesired behaviour.  If a consumer actually *needs* this behaviour, we
should add new API with a more explicit name.

I added two testcases: one specifically for the -instcombine behaviour
and one for the LTO flow.

<rdar://problem/16165191>

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203513 91177308-0d34-0410-b5e6-96231b3b80d8
2014-03-10 23:42:28 +00:00
Benjamin Kramer
6e9eeab69f [C++11] Modernize the IR library a bit.
No functionality change.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203465 91177308-0d34-0410-b5e6-96231b3b80d8
2014-03-10 15:03:06 +00:00
Ahmed Charles
f4ccd11075 Replace OwningPtr<T> with std::unique_ptr<T>.
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.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203083 91177308-0d34-0410-b5e6-96231b3b80d8
2014-03-06 05:51:42 +00:00
Chandler Carruth
ca7680b998 [Layering] Move GVMaterializer.h into the IR library where its
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.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203069 91177308-0d34-0410-b5e6-96231b3b80d8
2014-03-06 03:50:29 +00:00
Chandler Carruth
8f124fe884 [Modules] Move the LeakDetector header into the IR library where the
source file had already been moved. Also move the unittest into the IR
unittest library.

This may seem an odd thing to put in the IR library but we only really
use this with instructions and it needs the LLVM context to work, so it
is intrinsically tied to the IR library.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202842 91177308-0d34-0410-b5e6-96231b3b80d8
2014-03-04 12:46:06 +00:00
Rafael Espindola
3f0a9af13b Fix resetting the DataLayout in a Module.
No tool does this currently, but as everything else in a module we should be
able to change its DataLayout.

Most of the fix is in DataLayout to make sure it can be reset properly.

The test uses Module::setDataLayout since the fact that we mutate a DataLayout
is an implementation detail. The module could hold a OwningPtr<DataLayout> and
the DataLayout itself could be immutable.

Thanks to Philip Reames for pushing me in the right direction.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202198 91177308-0d34-0410-b5e6-96231b3b80d8
2014-02-25 22:23:04 +00:00
Rafael Espindola
aab87fe0ec Store a DataLayout in Module.
Now that DataLayout is not a pass, store one in Module.

Since the C API expects to be able to get a char* to the datalayout description,
we have to keep a std::string somewhere. This patch keeps it in Module and also
uses it to represent modules without a DataLayout.

Once DataLayout is mandatory, we should probably move the string to DataLayout
itself since it won't be necessary anymore to represent the special case of a
module without a DataLayout.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202190 91177308-0d34-0410-b5e6-96231b3b80d8
2014-02-25 20:01:08 +00:00
Rafael Espindola
1dc66089e6 Return an error_code from materializeAllPermanently.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199275 91177308-0d34-0410-b5e6-96231b3b80d8
2014-01-14 23:51:27 +00:00
Rafael Espindola
06a3bddb36 Use error_code in Module::materializeAll.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199269 91177308-0d34-0410-b5e6-96231b3b80d8
2014-01-14 23:02:01 +00:00
Nadav Rotem
4804692491 Re-remove dead code.
This reverts r198854.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@198879 91177308-0d34-0410-b5e6-96231b3b80d8
2014-01-09 19:22:07 +00:00
Nadav Rotem
7b651ce261 Revert r198819 - "Remove dead code."
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@198854 91177308-0d34-0410-b5e6-96231b3b80d8
2014-01-09 07:50:34 +00:00
Rafael Espindola
0b5675926a Remove dead code.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@198819 91177308-0d34-0410-b5e6-96231b3b80d8
2014-01-09 00:32:54 +00:00
Dmitri Gribenko
8d6a09de7d When parsing data layout string looking for endianness, use the correct default
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197771 91177308-0d34-0410-b5e6-96231b3b80d8
2013-12-20 02:54:35 +00:00
Dmitri Gribenko
ea5893eb2d Correctly apply the default pointer size
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197770 91177308-0d34-0410-b5e6-96231b3b80d8
2013-12-20 02:46:23 +00:00
Manman Ren
7d318bd116 Debug Info: drop debug info via upgrading path if version number does not match.
Add a helper function getDebugInfoVersionFromModule to return the debug info
version number for a module.

"Verifier/module-flags-1.ll" checks for verification errors.
It will seg fault when calling getDebugInfoVersionFromModule because of the
incorrect format for module flags in the testing case. We make
getModuleFlagsMetadata more robust by checking for error conditions.

PR17982


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@196158 91177308-0d34-0410-b5e6-96231b3b80d8
2013-12-02 21:29:56 +00:00
Rafael Espindola
af9e8e60ae Use error_code in GVMaterializer.
They just propagate out the bitcode reader error, so we don't need a new enum.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194091 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-05 19:36:34 +00:00
Matt Arsenault
b1d70af7b9 Reuse variable
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191712 91177308-0d34-0410-b5e6-96231b3b80d8
2013-09-30 23:31:50 +00:00
Matt Arsenault
2ebcd57e6a Fix getOrInsertGlobal dropping the address space.
Currently it will insert an illegal bitcast.
Arguably, the address space argument should be
added for the creation case.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191702 91177308-0d34-0410-b5e6-96231b3b80d8
2013-09-30 21:23:03 +00:00
Matt Arsenault
f625c14487 Fix typo
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191595 91177308-0d34-0410-b5e6-96231b3b80d8
2013-09-28 01:08:00 +00:00
Rafael Espindola
2d680824e3 Make these methods const correct.
Thanks to Nick Lewycky for noticing it.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187098 91177308-0d34-0410-b5e6-96231b3b80d8
2013-07-25 02:50:08 +00:00
Manman Ren
c8cfaa1625 Add getModuleFlag(StringRef Key) to query a module flag given Key.
No functionality change.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186470 91177308-0d34-0410-b5e6-96231b3b80d8
2013-07-16 23:21:16 +00:00
Eli Bendersky
2aa6db98df Remove dead code.
This method is not being used/tested anywhere.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181943 91177308-0d34-0410-b5e6-96231b3b80d8
2013-05-15 22:41:28 +00:00
Jean-Luc Duprat
c2171eb3ff Removed extraneous #include "LLVMContextImpl.h" from lib/IR/Module.cpp
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@176382 91177308-0d34-0410-b5e6-96231b3b80d8
2013-03-01 21:37:24 +00:00
Michael Ilseman
4c8e74f0b7 Cache the result of Function::getIntrinsicID() in a DenseMap attached to the LLVMContext.
This reduces the time actually spent doing string to ID conversion and shows a 10% improvement in compile time for a particularly bad case that involves ARM Neon intrinsics (these have many overloads).

Patch by Jean-Luc Duprat!



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@176365 91177308-0d34-0410-b5e6-96231b3b80d8
2013-03-01 18:48:54 +00:00
Chandler Carruth
0b8c9a80f2 Move all of the header files which are involved in modelling the LLVM IR
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.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171366 91177308-0d34-0410-b5e6-96231b3b80d8
2013-01-02 11:36:10 +00:00
Chandler Carruth
c2c50cdcdc Rename VMCore directory to IR.
Aside from moving the actual files, this patch only updates the build
system and the source file comments under lib/... that are relevant.

I'll be updating other docs and other files in smaller subsequnet
commits.

While I've tried to test this, but it is entirely possible that there
will still be some build system fallout.

Also, note that I've not changed the library name itself: libLLVMCore.a
is still the library name. I'd be interested in others' opinions about
whether we should rename this as well (I think we should, just not sure
what it might break)

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171359 91177308-0d34-0410-b5e6-96231b3b80d8
2013-01-02 09:10:48 +00:00