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.
llvm-svn: 140379
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.
llvm-svn: 140303
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.
llvm-svn: 140301
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.
llvm-svn: 134985
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.
llvm-svn: 134901
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.
llvm-svn: 96949
work anyway (Interpreter::getPointerToFunction doesn't return a
callable pointer), and improve the error message when an
ExecutionEngine can't be created.
llvm-svn: 95896
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).
llvm-svn: 95723
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.
llvm-svn: 94686
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.
llvm-svn: 86311
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.
llvm-svn: 86077
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.
llvm-svn: 84292
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.
llvm-svn: 79990
This involves temporarily hard wiring some parts to use the global context. This isn't ideal, but it's
the only way I could figure out to make this process vaguely incremental.
llvm-svn: 75445
Garrison Venn