Re-fix the issue Bill fixed in r147899 in a slightly different way, which doesn't abuse the semantics of linker_private.  We don't really want to merge any string constant with a weak_odr global.

llvm-svn: 147971

with other symbols.

An object in the __cfstring section is suppoed to be filled with CFString
objects, which have a pointer to ___CFConstantStringClassReference followed by a
pointer to a __cstring. If we allow the object in the __cstring section to be
merged with another global, then it could end up in any section. Because the
linker is going to remove these symbols in the final executable, we shouldn't
bother to merge them.
<rdar://problem/10564621>

llvm-svn: 147899

PR11705, part 2: globalopt shouldn't put inttoptr/ptrtoint operations into global initializers if there's an implied extension or truncation.

llvm-svn: 147625

Eliminate the dead test for it on each loop iteration. No functionality change.

llvm-svn: 147616

captured. This allows the tracker to look at the specific use, which may be
especially interesting for function calls.

Use this to fix 'nocapture' deduction in FunctionAttrs. The existing one does
not iterate until a fixpoint and does not guarantee that it produces the same
result regardless of iteration order. The new implementation builds up a graph
of how arguments are passed from function to function, and uses a bottom-up walk
on the argument-SCCs to assign nocapture. This gets us nocapture more often, and
does so rather efficiently and independent of iteration order.

llvm-svn: 147327

llvm-svn: 146409

llvm-svn: 146037

Add FIXMEs to places that are non-trivial to fix.

llvm-svn: 145661

where it appeared beneficial to pass.
More of rdar://10500969

llvm-svn: 145630

llvm-svn: 145530

llvm-svn: 145420

llvm-svn: 144648

build: Attempt to rectify inconsistencies between CMake and LLVMBuild versions of explicit dependencies.
 - The hope is that we have a tool/test to verify these are accurate (and tight) soon.

llvm-svn: 144444

llvm-svn: 144416

llvm-svn: 143634

Refactor code from inlining and globalopt that checks whether a function definition is unused, and enhance it so it can tell that functions which are only used by a blockaddress are in fact dead.  This probably doesn't happen much on most code, but the Linux kernel's _THIS_IP_ can trigger this issue with blockaddress.  (GlobalDCE can also handle the given tescase, but we only run that at -O3.)  Found while looking at PR11180.

llvm-svn: 142572

We want heuristics to be based on accurate data, but more importantly
we don't want llvm to behave randomly. A benign trunc inserted by an
upstream pass should not cause a wild swings in optimization
level. See PR11034. It's a general problem with threshold-based
heuristics, but we can make it less bad.

llvm-svn: 140919

llvm-svn: 140916

Stop emitting instructions with the name "tmp" they eat up memory and have to be uniqued, without any benefit.

If someone prefers %tmp42 to %42, run instnamer.

llvm-svn: 140634

Place the check for an exit landing pad where it will be run on both code paths through the if-then-else.

llvm-svn: 140195

The landing pad must accompany the invoke when it's extracted. However, if it
does, then the loop isn't properly extracted. I.e., the resulting extraction has
a loop in it. The extracted function is then extracted, etc. resulting in an
infinite loop.

llvm-svn: 140193

llvm-svn: 140176

extract its associated landing pad block as well. However, that landing pad
block may have more than one predecessor. So split the landing pad block so that
individual landing pads have only one predecessor.

This type of transformation may produce a false positive with bugpoint.

llvm-svn: 140173

C API functions must be able to see their extern "C" definitions, or it will be impossible to call them from C.

llvm-svn: 138022

Add a mechanism for optimisation plugins to register passes that all front ends can use without needing to be aware of the plugin (or the plugin be aware of the front end).

Before 3.0, I'd like to add a mechanism for automatically loading a set of plugins from a config file.  API suggestions welcome...

llvm-svn: 137717

llvm-svn: 137702

llvm-svn: 137693

llvm-svn: 137667

llvm-svn: 137627

llvm-svn: 137480

functionality since in the C api a pass is created and added to a pass
manager in a single call.

llvm-svn: 137159

This is some of my original LLVM code. *wipes tear*

llvm-svn: 136821

llvm-svn: 136727

This adds the 'resume' instruction class, IR parsing, and bitcode reading and
writing. The 'resume' instruction resumes propagation of an existing (in-flight)
exception whose unwinding was interrupted with a 'landingpad' instruction (to be
added later).

llvm-svn: 136589

r136339, r136341, r136369, r136387, r136392, r136396, r136429, r136430, r136444,
r136445, r136446, r136253 pending review.

llvm-svn: 136556

working on x86 (at least for trivial testcases); other architectures will
need more work so that they actually emit the appropriate instructions for
orderings stricter than 'monotonic'. (As far as I can tell, the ARM, PPC,
Mips, and Alpha backends need such changes.)

llvm-svn: 136457

specified in the same file that the library itself is created. This is
more idiomatic for CMake builds, and also allows us to correctly specify
dependencies that are missed due to bugs in the GenLibDeps perl script,
or change from compiler to compiler. On Linux, this returns CMake to
a place where it can relably rebuild several targets of LLVM.

I have tried not to change the dependencies from the ones in the current
auto-generated file. The only places I've really diverged are in places
where I was seeing link failures, and added a dependency. The goal of
this patch is not to start changing the dependencies, merely to move
them into the correct location, and an explicit form that we can control
and change when necessary.

This also removes a serialization point in the build because we don't
have to scan all the libraries before we begin building various tools.
We no longer have a step of the build that regenerates a file inside the
source tree. A few other associated cleanups fall out of this.

This isn't really finished yet though. After talking to dgregor he urged
switching to a single CMake macro to construct libraries with both
sources and dependencies in the arguments. Migrating from the two macros
to that style will be a follow-up patch.

Also, llvm-config is still generated with GenLibDeps.pl, which means it
still has slightly buggy dependencies. The internal CMake
'llvm-config-like' macro uses the correct explicitly specified
dependencies however. A future patch will switch llvm-config generation
(when using CMake) to be based on these deps as well.

This may well break Windows. I'm getting a machine set up now to dig
into any failures there. If anyone can chime in with problems they see
or ideas of how to solve them for Windows, much appreciated.

llvm-svn: 136433

This adds the new instructions 'landingpad' and 'resume'.

llvm-svn: 136253

llvm-svn: 136250

llvm-svn: 136083