1,$s/llvm::Type::getInt\(..\)Ty(builder.getContext())/builder.getInt\1Ty()/g
1,$s/builder.getInt\(..*\)Ty()->getPointerTo()/builder.getInt\1PtrTy()/g
vi sub commands (second one was not a reversion but requested by
Tobias Grosser.
Mod was tested, but other examples have failed to build as they are currently
being thrashed with the const qualifier removal change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@134985 91177308-0d34-0410-b5e6-96231b3b80d8
type system. However most of these modifications were due to IRBuilder
(IRBuilderBase), not having been modified to NOT return such const qualified
free types. If IRBuilder does not change, as can also be seen in its
instruction creation methods, to use const free types, it may be useful to have
ExceptionDemo drop IRBuilder usage. Modifying builder.getInt32Ty() to
llvm::Type::getInt32Ty(builder.getContext()) is pretty ugly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@134901 91177308-0d34-0410-b5e6-96231b3b80d8
x86 and x86_64 on UNIX systems. Only OS X 10.6.2 (x86_64) and 32bit CentOS 5.2
with gcc 4.1.2 were tested. ARM UNIX build triggered failure motivating this
modification, as it seems that the ARM ABI does not support _Unwind_GetIP(...),
_Unwind_SetGR(...), and _Unwind_SetIP(...). From doing a quick browse of:
http://infocenter.arm.com/help/topic/com.arm.doc.ihi0038a/IHI0038A_ehabi.pdf,
it seems as if all other exception related apis are supported. Looks like
the port can be done to ARM. Thanks to Xerxes Rånby <xerxes@zafena.se> for
pointing out this error.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@96949 91177308-0d34-0410-b5e6-96231b3b80d8
work anyway (Interpreter::getPointerToFunction doesn't return a
callable pointer), and improve the error message when an
ExecutionEngine can't be created.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@95896 91177308-0d34-0410-b5e6-96231b3b80d8
Both zero cost example domain specific, and C++ foreign exception handling are
shown. The example's documentation fully explains how to run the example.
Notes:
1) The code uses an extremely simple type info model.
2) Only a single landing pad is used per unwind edge
(one call to llvm.eh.selector)
3) llvm.eh.selector support for filter arguments is not given.
4) llvm.eh.typeid.for is not used.
5) Forced unwind behavior is not supported.
6) Very little if any error handling is given.
7) __attribute__((__aligned__)) is used.
8) The code uses parts from the llvm compiler-rt project and
the llvm Kaleidoscope example.
9) The code has not been ported or tested on WINDOWS.
10) The code was not tested with a cmake build.
11) The code was tested for a debug build on 32bit X86 CentOS LINUX,
and both a debug and release build on OS X 10.6.2 (64bit).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@95723 91177308-0d34-0410-b5e6-96231b3b80d8
Modules and ModuleProviders. Because the "ModuleProvider" simply materializes
GlobalValues now, and doesn't provide modules, it's renamed to
"GVMaterializer". Code that used to need a ModuleProvider to materialize
Functions can now materialize the Functions directly. Functions no longer use a
magic linkage to record that they're materializable; they simply ask the
GVMaterializer.
Because the C ABI must never change, we can't remove LLVMModuleProviderRef or
the functions that refer to it. Instead, because Module now exposes the same
functionality ModuleProvider used to, we store a Module* in any
LLVMModuleProviderRef and translate in the wrapper methods. The bindings to
other languages still use the ModuleProvider concept. It would probably be
worth some time to update them to follow the C++ more closely, but I don't
intend to do it.
Fixes http://llvm.org/PR5737 and http://llvm.org/PR5735.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@94686 91177308-0d34-0410-b5e6-96231b3b80d8
