A catch (...) doesn't have a type descriptor.  Instead, the 'adjectives'
field has bit six set.

llvm-svn: 233788

MSVC treats all non-empty exception specifications the same way: all
exceptions are permitted.  The .xdata tables provide a way to
efficiently lower exception specifications *but* this probably has to be
implemented as a catch-all/rethrow mechanism instead of the Itanium way.

This fixes PR23092.

llvm-svn: 233787

This makes symbol resolution essentially identical between MCJIT and the LLI
Orc-lazy JIT.

llvm-svn: 233786

Added sema checks for forms of expressions/statements allowed under control of 'atomic capture' directive + generation of helper objects for future codegen.

llvm-svn: 233785

Not having this breaks clang builds that use an already-built LLVM.

llvm-svn: 233784

No functional changes.

llvm-svn: 233783

llvm-svn: 233782

llvm-svn: 233781

llvm-svn: 233780

version of this script.  We picked up a bug at some point in March
where scripts that fail to call SBDebugger::Destroy() will crash
in the Debugger C++ dtor.  I want to track the change down which
introduced the change - but this script should be calling
SBDebugger::Destroy() in the first place, so do that.

llvm-svn: 233779

llvm-svn: 233778

We used to do this before refactorings around r225640.
Some clang users checked for _chk libcall availability using:
  __has_builtin(__builtin___memcpy_chk)
When compiling with -fno-builtin, this is always true.
When passing -ffreestanding/-mkernel, which both imply -fno-builtin, we
end up with fortified libcalls, which isn't acceptable in a freestanding
environment which only provides their non-fortified counterparts.

Until we change clang and/or teach external users to check for availability
differently, disregard the "nobuiltin" attribute and TLI::has.

Workaround for PR23093.

llvm-svn: 233776

Under normal circumstances, use of CR bits is disabled when running at -O0, but
it is enabled by default otherwise, and if you have optnone functions, they'll
still generally be generated with crbits turned on (because nothing else turns
them off). FastISel can't handle most things dealing with i1 values when using
CR bits, and checks for that, but was not checking the return type on
functions; we can't fast-isel function calls with i1 return values either when
using CR bits for boolean values.

Fixes PR22664.

llvm-svn: 233775

This patch updates comments in the ELFLinkingContext to use
non-question sentences as brief descriptions of functions.

llvm-svn: 233774

In r233772, I removed an empty class, DefaultTargetHandler, from
the class hierarchy by merging the class with TargetHandler. I then
found that TargetHandler and its base class, TargetHandlerBase,
are also almost the same.

We need to go deeper.

In this patch, I merged TargetHandlerBase with TargetHandler.
The only difference between them is the existence (or absense)
of a pure virtual function registerRelocationName(). I added that
function to the (new) TargetHandler.

One more thing is that TargetHandler was templated for no reason.
I made it non-templated class.

llvm-svn: 233773

DefaultTargetHandler is the base class of all <Arch>TargetHandler classes,
and it's the only derived class of TargetHandler class.

TargetHandler and DefaultTargetHandler are actually the same. They define
the same set of pure virtual functions. DefaultTargetHandler is a useless
class in the class hierarchy -- it shouldn't have been added in the first place.

This patch makes all <Arch>TargetHandler classes directly derive from
TargetHandler and removes DefaultTargetHandler.

llvm-svn: 233772

Based on a patch by Stanislav Manilov!

llvm-svn: 233771

Remove a redundant condition, no functional change intended.

llvm-svn: 233770

All calls of findAbsoluteAtoms seem a bit awkward because of the type
of the function. It semantically returns a pointer to an AtomLayout or
nothing, so I made the function return AtomLayout*.

In this patch, I also expanded some "auto"s because their actual type
were not obvious in their contexts.

llvm-svn: 233769

Reviewers: clayborg, ovyalov, chaoren

Reviewed By: chaoren

Subscribers: lldb-commits

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

llvm-svn: 233768

This lets us catch exceptions in simple cases.

N.B. Things that do not work include (but are not limited to):
- Throwing from within a catch handler.
- Catching an object with a named catch parameter.
- 'CatchHigh' is fictitious, we aren't sure of its purpose.
- We aren't entirely efficient with regards to the number of EH states
  that we generate.
- IP-to-State tables are sensitive to the order of emission.

llvm-svn: 233767

Protocol objects in OBJC2. rdar://20286356

llvm-svn: 233766

findAbsoluteAtom() returns absoluteAtom().end() if no atom is found.
Dereferencing end() value results an undefined behavior.

llvm-svn: 233765

llvm-svn: 233764

llvm-svn: 233763

llvm-svn: 233762

llvm-svn: 233761

replaceWithUniquedUnresolved
replaceWithUniquedUnresolvedChangedOperand
 =>
replaceWithUniquedResolvingOperand
replaceWithUniquedChangingOperand

I find the new names less confusing; they're also more accurate.  Sorry
for the churn.

llvm-svn: 233759

In an effort to reduce binary size for components not wishing to
link against all of LLDB, as well as a parallel effort to reduce
link dependencies on Python, this patch splits out the notion of
LLDB initialization into "full" and "common" initialization.

All code related to initializing the full LLDB suite lives directly
in API now.  Previously it was only referenced from API, but because
it was defined in lldbCore, it would get implicitly linked against
by everything including lldb-server, causing a considerable
increase in binary size.

By moving this to the API layer, it also creates a better layering
for the ongoing effort to make the embedded interpreter replacable
with one from a different language (or even be completely removeable).

One semantic change necessary to get this all working was to remove
the notion of a shared debugger refcount.  The debugger is either
initialized or uninitialized now, and calling Initialize() multiple
times will simply have no effect, while the first Terminate() will
now shut it down no matter how many times Initialize() was called.
This behaves nicely with all of our supported usage patterns though,
and allows us to fix a number of nasty hacks from before.

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

llvm-svn: 233758

I am fixing this by:
1 - make sure we aren't trying to set the symbol file for a module to the same thing it already has and leaving it alone if it is the same
2 - keep all old symbol files around in the module in case there are any outstanding type references

<rdar://problem/18029116>

llvm-svn: 233757

r233664 fixed the `Verifier` so that it doesn't crash on bad type refs.
This deserves a test!

llvm-svn: 233756

Even at -O0, we fall back to SDAG when we hit intrinsics, and if the intrinsic
is a memset/memcpy/etc. we might normally use vector types. At -O0, this is
probably not a good idea (because, if there is a bug in the lowering code,
there would be no good way to turn it off). At -O0, only use scalar preferred
types.

Related to PR22754.

llvm-svn: 233755

llvm-svn: 233754

extended loads.
Implement the related target lowering hook so that the optimization has a better
estimation of the cost of an extension.

rdar://problem/19267165

llvm-svn: 233753

llvm-svn: 233752

Uniqued nodes have more complete registration with
`ReplaceableMetadataImpl` so that they can update themselves when
operands change.  Fix a bug where `MDNode::replaceWithUniqued()` wasn't
enabling these callbacks.

The two most obvious ways missing callbacks causes problems is that
auto-resolution fails and re-uniquing (on changed operands) just doesn't
happen.  I've added tests for both -- in both cases, I confirmed that
the final check was failing before the fix.

rdar://problem/20365935

llvm-svn: 233751

Commit r233747 fixed the issue that had been blocking this.

llvm-svn: 233750

The existing code in getMemsetValue only handled integer-preferred types when
the fill value was not a constant. Make this more robust in two ways:

  1. If the preferred type is a floating-point value, do the mul-splat trick on
     the corresponding integer type and then bitcast.
  2. If the preferred type is a vector, do the mul-splat trick on one vector
     element, and then build a vector out of them.

Fixes PR22754 (although, we should also turn off use of vector types at -O0).

llvm-svn: 233749

Only MIPS used that member function, and by removing the use of the
function, I removed a static_cast. Seems like it's a win.

llvm-svn: 233748

This patch fixes MCJIT::addGlobalMapping by changing the implementation of the
ExecutionEngineState class. The new implementation maintains a bidirectional
mapping between symbol names (std::strings) and addresses (uint64_ts), rather
than a mapping between Value*s and void*s.

This has fix has been made for backwards compatibility, however the strongly
preferred way to resolve unknown symbols is by writing a custom
RuntimeDyld::SymbolResolver (formerly RTDyldMemoryManager) and overriding the
findSymbol method. The addGlobalMapping method is a hangover from the legacy JIT
(which has was removed in 3.6), and may be deprecated in a future release as
part of a clean-up of the ExecutionEngine interface.

Patch by Murat Bolat. Thanks Murat!

llvm-svn: 233747