llvm-svn: 195173

The object files we support use null terminated strings, so there is no way to
support these.

This patch adds an assert to catch bad API use and an error check in the .ll
parser.

llvm-svn: 195155

llvm-svn: 195153

Added constness to methods that shouldn't modify objects. Replaced
operator[] lookup in maps with find() instead.

llvm-svn: 195151

llvm-svn: 195150

This patch removes most of the trivial cases of weak vtables by pinning them to
a single object file. The memory leaks in this version have been fixed. Thanks
Alexey for pointing them out.

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

Reviewed by Andy

llvm-svn: 195064

DebugInfo: Simplify a few more explicit constructions, underconstrained types, and make DIType(MDNode*) explicit like all the other DI* node ctors.

llvm-svn: 195055

(except functions marked always_inline).
Functions with 'optnone' must also have 'noinline' so they don't get
inlined into any other function.

Based on work by Andrea Di Biagio.

llvm-svn: 195046

This change is incorrect. If you delete virtual destructor of both a base class
and a subclass, then the following code:
  Base *foo = new Child();
  delete foo;
will not cause the destructor for members of Child class. As a result, I observe
plently of memory leaks. Notable examples I investigated are:
ObjectBuffer and ObjectBufferStream, AttributeImpl and StringSAttributeImpl.

llvm-svn: 194997

Debug info verifier is part of the verifier which is a Function Pass.
Tot currently tries to pull all reachable debug info MDNodes in each function,
which is too time-consuming. The correct fix seems to be separating debug info
verification to its own module pass.

I will disable the debug info verifier until a correct fix is found.

For Bill's testing case, enabling debug info verifier increase compile
time from 11s to 11m.

llvm-svn: 194986

llvm-svn: 194975

We used to collect debug info MDNodes in doInitialization and verify them in
doFinalization. That is incorrect since MDNodes can be modified by passes run
between doInitialization and doFinalization.

To fix the problem, we handle debug info MDNodes that can be reached from a
function in runOnFunction (i.e we collect those nodes by calling processDeclare,
processValue and processLocation, and then verify them in runOnFunction).

We handle debug info MDNodes that can be reached from named metadata in
doFinalization. This is in line with how Verifier handles module-level data
(they are verified in doFinalization).

rdar://15472296

llvm-svn: 194974

We used to depend on running processModule before the other public functions
such as processDeclare, processValue and processLocation. We are now relaxing
the constraint by adding a module argument to the three functions and
letting the three functions to initialize the type map. This will be used in
a follow-on patch that collects nodes reachable from a Function.

llvm-svn: 194973

No functionality change.

llvm-svn: 194917

This patch removes most of the trivial cases of weak vtables by pinning them to
a single object file.

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

Reviewed by Andy

llvm-svn: 194865

AaronBallman. Thanks for the excellent review.

llvm-svn: 194857

pulling them under 80-columns. No functionality changed.

llvm-svn: 194856

llvm-svn: 194799

Patch by Michele Scandale!

llvm-svn: 194760

llvm-svn: 194693

llvm-svn: 194692

- readInt() should check all 4 bytes can be read, not just 1.
- In the event of false data in the gcno file, it was possible to index
  into a non-existent index of SmallVector, causing assertion error.

llvm-svn: 194639

According to the hazy gcov documentation, it appeared to be technically
possible for lines within a block to belong to different source files.
However, upon further investigation, gcov does not actually support
multiple source files for a single block.

This change removes a level of separation between blocks and lines by
replacing the StringMap of GCOVLines with a SmallVector of ints
representing line numbers. This also means that the GCOVLines class is
no longer needed.

This paves the way for supporting the "-a" option, which will output
block information.

llvm-svn: 194637

Unified the interface for read functions. They all return a boolean
indicating if the read from file succeeded. Functions that previously
returned the read value now store it into a variable that is passed in
by reference instead. Callers will need to check the return value to
detect if an error occurred.

Also added a new test which ensures that no assertions occur when file
contains invalid data. llvm-cov should return with error code 1 upon
failure.

llvm-svn: 194635

verifyFunction needs to call doInitialization to collect metadata and avoid
crashing when verifying debug info in a function.

But it should not call doFinalization since that is where the verifier will
check declarations, variables and aliases, which is not desirable when one
only wants to verify a function.

A possible cleanup would be to split the class into a ModuleVerifier and
FunctionVerifier.

Issue reported by Ilia Filippov. Patch by Michael Kruse.

llvm-svn: 194574

more smarts in it. This is where most of the interesting logic that used
to live in the implicit-scheduling-hackery of the old pass manager will
live.

Like the previous commits, note that this is a very early prototype!
I expect substantial changes before this is ready to use.

The core of the design is the following:

- We have an AnalysisManager which can be used across a series of
  passes over a module.
- The code setting up a pass pipeline registers the analyses available
  with the manager.
- Individual transform passes can check than an analysis manager
  provides the analyses they require in order to fail-fast.
- There is *no* implicit registration or scheduling.
- Analysis passes are different from other passes: they produce an
  analysis result that is cached and made available via the analysis
  manager.
- Cached results are invalidated automatically by the pass managers.
- When a transform pass requests an analysis result, either the analysis
  is run to produce the result or a cached result is provided.

There are a few aspects of this design that I *know* will change in
subsequent commits:
- Currently there is no "preservation" system, that needs to be added.
- All of the analysis management should move up to the analysis library.
- The analysis management needs to support at least SCC passes. Maybe
  loop passes. Living in the analysis library will facilitate this.
- Need support for analyses which are *both* module and function passes.
- Need support for pro-actively running module analyses to have cached
  results within a function pass manager.
- Need a clear design for "immutable" passes.
- Need support for requesting cached results when available and not
  re-running the pass even if that would be necessary.
- Need more thorough testing of all of this infrastructure.

There are other aspects that I view as open questions I'm hoping to
resolve as I iterate a bit on the infrastructure, and especially as
I start writing actual passes against this.
- Should we have separate management layers for function, module, and
  SCC analyses? I think "yes", but I'm not yet ready to switch the code.
  Adding SCC support will likely resolve this definitively.
- How should the 'require' functionality work? Should *that* be the only
  way to request results to ensure that passes always require things?
- How should preservation work?
- Probably some other things I'm forgetting. =]

Look forward to more patches in shorter order now that this is in place.

llvm-svn: 194538

llvm-svn: 194427

llvm-svn: 194383

llvm-svn: 194341

give the files a legacy prefix in the right directory. Use forwarding
headers in the old locations to paper over the name change for most
clients during the transitional period.

No functionality changed here! This is just clearing some space to
reduce renaming churn later on with a new system.

Even when the new stuff starts to go in, it is going to be hidden behind
a flag and off-by-default as it is still WIP and under development.

This patch is specifically designed so that very little out-of-tree code
has to change. I'm going to work as hard as I can to keep that the case.
Only direct forward declarations of the PassManager class are impacted
by this change.

llvm-svn: 194324

llvm-svn: 194251

No additional test was needed, Other/constant-fold-gep.ll detects this
just fine.

llvm-svn: 194221

Summary:
Consider a GEP of:
i8* getelementptr ({ [2 x i8], i32, i8, [3 x i8] }* @main.c, i32 0, i32 0, i64 0)

If we proceeded to GEP the aforementioned object by 8, would form a GEP of:
i8* getelementptr ({ [2 x i8], i32, i8, [3 x i8] }* @main.c, i32 0, i32 0, i64 8)

Note that we would go through the first array member, causing an
out-of-bounds accesses.  This is problematic because we might get fooled
if we are trying to evaluate loads using this GEP, for example, based
off of an object with a constant initializer where the array is zero.

This fixes PR17732.

Reviewers: nicholas, chandlerc, void

Reviewed By: void

CC: llvm-commits, echristo, void, aemerson

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

llvm-svn: 194220

Original patch by Chris Wailes

llvm-svn: 194135

They just propagate out the bitcode reader error, so we don't need a new enum.

llvm-svn: 194091

This reverts commit d8acf0078cf363252727acff00f85ae8074f95b3.

llvm-svn: 194040

This will allow for much easier testing when the input files are in a
different folder from the test script.

llvm-svn: 194034

This patch enables llvm-cov to correctly output the run count stored in
the GCDA file. GCOVProfiling currently does not generate this
information, so the GCDA run data had to be hacked on from a GCDA file
generated by gcc. This is corrected by a subsequent patch.

With the run and program data included, both llvm-cov and gcov produced
the same output.

llvm-svn: 194033

Added -o option to llvm-cov. If no output file is specified, it defaults
to STDOUT.

llvm-svn: 193899

linkonce_odr_auto_hide was in incomplete attempt to implement a way
for the linker to hide symbols that are known to be available in every
TU and whose addresses are not relevant for a particular DSO.

It was redundant in that it all its uses are equivalent to
linkonce_odr+unnamed_addr. Unlike those, it has never been connected
to clang or llvm's optimizers, so it was effectively dead.

Given that nothing produces it, this patch just nukes it
(other than the llvm-c enum value).

llvm-svn: 193865