llvm-svn: 46628

Add an extra operand to LABEL nodes which distinguishes between debug, EH, or misc labels. This fixes the EH breakage. However I am not convinced this is *the* solution.

llvm-svn: 46609

llvm-svn: 46569

legitimate way of representing global variable GV in debug info.

llvm-svn: 46565

llvm-svn: 46514

associated function is so marked.

llvm-svn: 46088

llvm-svn: 45697

llvm-svn: 45418

to know about calls that cannot throw ('nounwind'):
if such a call does throw for some reason then the
personality will terminate the program.  The distinction
between an ordinary call and a nounwind call is that
an ordinary call gets an entry in the exception table
but a nounwind call does not.  This patch sets up the
exception table appropriately.  One oddity is that
I've chosen to bracket nounwind calls with labels (like
invokes) - the other choice would have been to bracket
ordinary calls with labels.  While bracketing
ordinary calls is more natural (because bracketing
by labels would then correspond exactly to getting an
entry in the exception table), I didn't do it because
introducing labels impedes some optimizations and I'm
guessing that ordinary calls occur more often than
nounwind calls.  This fixes the gcc filter2 eh test,
at least at -O0 (the inliner needs some tweaking at
higher optimization levels).

llvm-svn: 45197

Change the PointerType api for creating pointer types. The old functionality of PointerType::get() has become PointerType::getUnqual(), which returns a pointer in the generic address space. The new prototype of PointerType::get() requires both a type and an address space.

llvm-svn: 45082

llvm-svn: 44446

labels are generated bracketing each call (not just
invokes).  This is used to generate entries in
the exception table required by the C++ personality.
However it gets in the way of tail-merging.  This
patch solves the problem by no longer placing labels
around ordinary calls.  Instead we generate entries
in the exception table that cover every instruction
in the function that wasn't covered by an invoke
range (the range given by the labels around the invoke).
As an optimization, such entries are only generated for
parts of the function that contain a call, since for
the moment those are the only instructions that can
throw an exception [1].  As a happy consequence, we
now get a smaller exception table, since the same
region can cover many calls.  While there, I also
implemented folding of invoke ranges - successive
ranges are merged when safe to do so.  Finally, if
a selector contains only a cleanup, there's a special
shorthand for it - place a 0 in the call-site entry.
I implemented this while there.  As a result, the
exception table output (excluding filters) is now
optimal - it cannot be made smaller [2].  The
problem with throw filters is that folding them
optimally is hard, and the benefit of folding them is
minimal.

[1] I tested that having trapping instructions (eg
divide by zero) in such a region doesn't cause trouble.
[2] It could be made smaller with the help of higher
layers, eg by having branch folding reorder basic blocks
ending in invokes with the same landing pad so they
follow each other.  I don't know if this is worth doing.

llvm-svn: 41718

gcc exception handling: if an exception unwinds through
an invoke, then execution must branch to the invoke's
unwind target.  We previously tried to enforce this by
appending a cleanup action to every selector, however
this does not always work correctly due to an optimization
in the C++ unwinding runtime: if only cleanups would be
run while unwinding an exception, then the program just
terminates without actually executing the cleanups, as
invoke semantics would require.  I was hoping this
wouldn't be a problem, but in fact it turns out to be the
cause of all the remaining failures in the LLVM testsuite
(these also fail with -enable-correct-eh-support, so turning
on -enable-eh didn't make things worse!).  Instead we need
to append a full-blown catch-all to the end of each
selector.  The correct way of doing this depends on the
personality function, i.e. it is language dependent, so
can only be done by gcc.  Thus this patch which generalizes
the eh.selector intrinsic so that it can handle all possible
kinds of action table entries (before it didn't accomodate
cleanups): now 0 indicates a cleanup, and filters have to be
specified using the number of type infos plus one rather than
the number of type infos.  Related gcc patches will cause
Ada to pass a cleanup (0) to force the selector to always
fire, while C++ will use a C++ catch-all (null).

llvm-svn: 41484

This patch fills the last necessary bits to enable exceptions
handling in LLVM. Currently only on x86-32/linux.

In fact, this patch adds necessary intrinsics (and their lowering) which
represent really weird target-specific gcc builtins used inside unwinder.

After corresponding llvm-gcc patch will land (easy) exceptions should be
more or less workable. However, exceptions handling support should not be 
thought as 'finished': I expect many small and not so small glitches
everywhere.

llvm-svn: 39855

exception handling table if we encounter it multiple
times.  Filters could be folded harder than this, but
that would mean a lot more work for not much gain.

llvm-svn: 37908

(landing pad) when an exception unwinds through the call.  This doesn't
quite match the way the dwarf unwinder works: by default it only jumps to
the landing pad if the catch or filter specification matches, and otherwise
it keeps on unwinding.  There are two ways of specifying to the unwinder
that it should "always" (more on why there are quotes here later) jump to
the landing pad: follow the specification by a 0 typeid, or follow it by
the typeid for the NULL typeinfo.  GCC does the first, and this patch makes
LLVM do the same as gcc.  However there is a problem: the unwinder performs
optimizations based on C++ semantics (it only expects destructors to be
run if the 0 typeid fires - known as "cleanups"), meaning it assumes that no
exceptions will be raised and that the raised exception will be reraised
at the end of the cleanup code.  So if someone writes their own LLVM code
using the exception intrinsics they will get a nasty surprise if they don't
follow these rules.  The other possibility of using the typeid corresponding
to NULL (catch-all) causes the unwinder to make no assumptions, so this is
probably what we should use in the long-run.  However since we are still
having trouble getting exception handling working properly, for the moment
it seems best to closely imitate GCC.

llvm-svn: 37399

simplifies the code in DwarfWriter, allows for multiple filters and
makes it trivial to specify filters accompanied by cleanups or catch-all
specifications (see next patch).  What a deal!  Patch blessed by Anton.

llvm-svn: 37398

Mark all calls as "could throw", when exceptions are enabled. Emit necessary LP info too. This fixes PR1439

llvm-svn: 37311

functions. This partly fixes PR1414: now we're restricted only to one
personality function per eh frame, not per module. Further work on
"multiple personalities" topic needs representative example.

llvm-svn: 37018

1. Fix PR1380
2. Apply Duncan's patch from PR1410
3. Insert workaround for "one personality function per module" as noted in PR1414
4. Emit correct debug frames for x86/linux. This partly fixes DebugInfo/2006-11-06-StackTrace.cpp: stack trace is
shown correctly, but arguments for function on top of stack are displayed incorrectly.

llvm-svn: 37015

llvm-svn: 36998

llvm-svn: 36978

llvm-svn: 36977

llvm-svn: 36662

Due to darwin gcc bug, one version of darwin linker coalesces
static const int, which defauts PassID based pass identification.

llvm-svn: 36652

llvm-svn: 36648

llvm-svn: 36632

llvm-svn: 34804

llvm-svn: 34473

llvm-svn: 33755

llvm-svn: 33641

llvm-svn: 33552

llvm-svn: 33537

by value so that clean up is less confusing (these vectors tend to be small.)

llvm-svn: 33488

recommended that getBoolValue be replaced with getZExtValue and that
get(bool) be replaced by get(const Type*, uint64_t). This implements
those changes.

llvm-svn: 33110

llvm-svn: 33076

Merge ConstantIntegral and ConstantBool into ConstantInt.
Remove ConstantIntegral and ConstantBool from LLVM.

llvm-svn: 33073

llvm-svn: 32835

Three changes:
1. Convert signed integer types to signless versions.
2. Implement the @sext and @zext parameter attributes. Previously the
   type of an function parameter was used to determine whether it should
   be sign extended or zero extended before the call. This information is
   now communicated via the function type's parameter attributes.
3. The interface to LowerCallTo had to be changed in order to accommodate
   the parameter attribute information. Although it would have been
   convenient to pass in the FunctionType itself, there isn't always one
   present in the caller. Consequently, a signedness indication for the
   result type and for each parameter was provided for in the interface
   to this method. All implementations were changed to make the adjustment
   necessary.

llvm-svn: 32788

llvm-svn: 32460