The old jit always uses DW_EH_PE_absptr, but MCJIT can use other encodings.
This is in preparation for adding EH support to MCJIT, but not directly
related, so I am committing it first.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@180883 91177308-0d34-0410-b5e6-96231b3b80d8
This was always part of the VMCore library out of necessity -- it deals
entirely in the IR. The .cpp file in fact was already part of the VMCore
library. This is just a mechanical move.
I've tried to go through and re-apply the coding standard's preferred
header sort, but at 40-ish files, I may have gotten some wrong. Please
let me know if so.
I'll be committing the corresponding updates to Clang and Polly, and
Duncan has DragonEgg.
Thanks to Bill and Eric for giving the green light for this bit of cleanup.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@159421 91177308-0d34-0410-b5e6-96231b3b80d8
llvm-ld is no longer useful and causes confusion and so it is being removed.
* Does not work very well on Windows because it must call a gcc like driver to
assemble and link.
* Has lots of hard coded paths which are wrong on many systems.
* Does not understand most of ld's options.
* Can be partially replaced by llvm-link | opt | {llc | as, llc -filetype=obj} |
ld, or fully replaced by Clang.
I know of no production use of llvm-ld, and hacking use should be
replaced by Clang's driver.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@155147 91177308-0d34-0410-b5e6-96231b3b80d8
Also conducted some reformatting. As the LLVM coding standard doc does not
seem to touch on how to align function arguments, and format code longer than
80 cols in general, the confusion persists. There is the golden rule, but as
this code has gone through several styles to deal with this, the golden rule
seems to be ignored. The latest reformatting effort tries to match the other
source files as much as possible.
Tested on OS X 10.7.1 with, and without the OLD_EXC_SYSTEM defined. Have NOT
tested on LINUX.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@140379 91177308-0d34-0410-b5e6-96231b3b80d8
was compiled and tested on OS X 10.7.1. It was not tested on LINUX. In
addition the defined OLD_EXC_SYSTEM was not tested with this version.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@140303 91177308-0d34-0410-b5e6-96231b3b80d8
infrastructure. As this makes the demo no longer a demo, and especially not a
demo on how to use the llvm exception mechanism, this hack will shortly be
changed to use the new 3.0 exception infrastructure. However for the time being
this demo is an example on how to use the AutoUpgrade
UpgradeExceptionHandling(...) function on < 3.0 exception handling code.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@140301 91177308-0d34-0410-b5e6-96231b3b80d8
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
Here is the original commit message:
This commit updates malloc optimizations to operate on malloc calls that have constant int size arguments.
Update CreateMalloc so that its callers specify the size to allocate:
MallocInst-autoupgrade users use non-TargetData-computed allocation sizes.
Optimization uses use TargetData to compute the allocation size.
Now that malloc calls can have constant sizes, update isArrayMallocHelper() to use TargetData to determine the size of the malloced type and the size of malloced arrays.
Extend getMallocType() to support malloc calls that have non-bitcast uses.
Update OptimizeGlobalAddressOfMalloc() to optimize malloc calls that have non-bitcast uses. The bitcast use of a malloc call has to be treated specially here because the uses of the bitcast need to be replaced and the bitcast needs to be erased (just like the malloc call) for OptimizeGlobalAddressOfMalloc() to work correctly.
Update PerformHeapAllocSRoA() to optimize malloc calls that have non-bitcast uses. The bitcast use of the malloc is not handled specially here because ReplaceUsesOfMallocWithGlobal replaces through the bitcast use.
Update OptimizeOnceStoredGlobal() to not care about the malloc calls' bitcast use.
Update all globalopt malloc tests to not rely on autoupgraded-MallocInsts, but instead use explicit malloc calls with correct allocation sizes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@86311 91177308-0d34-0410-b5e6-96231b3b80d8
MallocInst-autoupgrade users use non-TargetData-computed allocation sizes.
Optimization uses use TargetData to compute the allocation size.
Now that malloc calls can have constant sizes, update isArrayMallocHelper() to use TargetData to determine the size of the malloced type and the size of malloced arrays.
Extend getMallocType() to support malloc calls that have non-bitcast uses.
Update OptimizeGlobalAddressOfMalloc() to optimize malloc calls that have non-bitcast uses. The bitcast use of a malloc call has to be treated specially here because the uses of the bitcast need to be replaced and the bitcast needs to be erased (just like the malloc call) for OptimizeGlobalAddressOfMalloc() to work correctly.
Update PerformHeapAllocSRoA() to optimize malloc calls that have non-bitcast uses. The bitcast use of the malloc is not handled specially here because ReplaceUsesOfMallocWithGlobal replaces through the bitcast use.
Update OptimizeOnceStoredGlobal() to not care about the malloc calls' bitcast use.
Update all globalopt malloc tests to not rely on autoupgraded-MallocInsts, but instead use explicit malloc calls with correct allocation sizes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@86077 91177308-0d34-0410-b5e6-96231b3b80d8
Remove LowerAllocations pass.
Update some more passes to treate free calls just like they were treating FreeInst.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@85176 91177308-0d34-0410-b5e6-96231b3b80d8
Update testcases that rely on malloc insts being present.
Also prematurely remove MallocInst handling from IndMemRemoval and RaiseAllocations to help pass tests in this incremental step.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@84292 91177308-0d34-0410-b5e6-96231b3b80d8
This is conventional command-line tool behavior. -f now just means
"enable binary output on terminals".
Add a -f option to llvm-extract and llvm-link, for consistency.
Remove F_Force from raw_fd_ostream and enable overwriting and
truncating by default. Introduce an F_Excl flag to permit users to
enable a failure when the file already exists. This flag is
currently unused.
Update Makefiles and documentation accordingly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79990 91177308-0d34-0410-b5e6-96231b3b80d8
