| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 78656
|
|
|
|
| |
llvm-svn: 76447
|
|
|
|
|
|
|
|
|
| |
"private" symbols which the assember shouldn't strip, but which the linker may
remove after evaluation. This is mostly useful for Objective-C metadata.
This is plumbing, so we don't have a use of it yet. More to come, etc.
llvm-svn: 76385
|
|
|
|
| |
llvm-svn: 76216
|
|
|
|
| |
llvm-svn: 76214
|
|
|
|
| |
llvm-svn: 76198
|
|
|
|
|
|
| |
stuff. Patch by Zoltan Varga!
llvm-svn: 75842
|
|
|
|
|
|
| |
several unwanted dependencies.
llvm-svn: 75717
|
|
|
|
| |
llvm-svn: 75440
|
|
|
|
| |
llvm-svn: 75259
|
|
|
|
|
|
|
| |
these instructions, no autoupgrade or backwards compatibility support is
provided.
llvm-svn: 74991
|
|
|
|
| |
llvm-svn: 74836
|
|
|
|
|
|
|
|
|
|
| |
default to using the
default global context, while new *InContext() APIs have been added that take a LLVMContextRef parameter.
Apologies to anyone affected by this breakage.
llvm-svn: 74694
|
|
|
|
| |
llvm-svn: 74678
|
|
|
|
| |
llvm-svn: 74675
|
|
|
|
| |
llvm-svn: 74663
|
|
|
|
| |
llvm-svn: 74640
|
|
|
|
|
|
|
|
|
|
| |
LLVMContext through a lot
of the bitcode reader and ASM parser APIs, as well as supporting it in all of the tools.
Patches for Clang and LLVM-GCC to follow.
llvm-svn: 74614
|
|
|
|
|
|
|
|
| |
libraries instead of relinked objects, the interpreter, JIT, and native
target libraries were not being linked in to an ocaml program using the
ExecutionEngine.
llvm-svn: 74117
|
|
|
|
|
|
|
|
| |
C bindings. Change all the backend "Initialize" functions to have C linkage.
Change the "llvm/Config/Targets.def" header to use C-style comments to avoid
compile warnings.
llvm-svn: 74026
|
|
|
|
|
|
|
|
|
|
|
| |
assembler
Add lto_codegen_set_assembler_path() API which allows the linker to specify the
path to the assembler tool to run. When assembler is used (instead of compiler)
different command line options are used.
Add LTO_API_VERSION #define so clients (linkers) can conditionalize use of new APIs.
llvm-svn: 72823
|
|
|
|
|
|
|
| |
will make it more obvious what it represents, and stop
it being confused with the StoreSize.
llvm-svn: 71349
|
|
|
|
|
|
| |
Incomplete, but better than nothing.
llvm-svn: 71081
|
|
|
|
| |
llvm-svn: 70491
|
|
|
|
|
|
|
| |
an optimization level instead of a simple boolean telling it to generate code
"fast" or the other type of "fast".
llvm-svn: 70347
|
|
|
|
| |
llvm-svn: 69972
|
|
|
|
| |
llvm-svn: 68942
|
|
|
|
|
|
| |
linkage, so remove it.
llvm-svn: 66690
|
|
|
|
|
|
|
| |
linkage: this linkage type only applies to declarations,
but ODR is only relevant to globals with definitions.
llvm-svn: 66650
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
and extern_weak_odr. These are the same as the non-odr versions,
except that they indicate that the global will only be overridden
by an *equivalent* global. In C, a function with weak linkage can
be overridden by a function which behaves completely differently.
This means that IP passes have to skip weak functions, since any
deductions made from the function definition might be wrong, since
the definition could be replaced by something completely different
at link time. This is not allowed in C++, thanks to the ODR
(One-Definition-Rule): if a function is replaced by another at
link-time, then the new function must be the same as the original
function. If a language knows that a function or other global can
only be overridden by an equivalent global, it can give it the
weak_odr linkage type, and the optimizers will understand that it
is alright to make deductions based on the function body. The
code generators on the other hand map weak and weak_odr linkage
to the same thing.
llvm-svn: 66339
|
|
|
|
| |
llvm-svn: 66273
|
|
|
|
|
|
| |
Lennart Augustsson!
llvm-svn: 66272
|
|
|
|
| |
llvm-svn: 63927
|
|
|
|
|
|
| |
PR3364
llvm-svn: 62697
|
|
|
|
|
|
| |
suggested by Chris.
llvm-svn: 62099
|
|
|
|
| |
llvm-svn: 61253
|
|
|
|
|
|
| |
This operation can be used to build dyn_cast, isa, and cast.
llvm-svn: 61252
|
|
|
|
|
|
|
|
|
|
| |
- ability to insert previously created instructions using a builder
- creation of aliases
- creation of inline asm constants
Patch by Zoltan Varga!
llvm-svn: 61153
|
|
|
|
| |
llvm-svn: 60257
|
|
|
|
| |
llvm-svn: 58650
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
s/ParamAttr/Attribute/g
s/PAList/AttrList/g
s/FnAttributeWithIndex/AttributeWithIndex/g
s/FnAttr/Attribute/g
This sets the stage
- to implement function notes as function attributes and
- to distinguish between function attributes and return value attributes.
This requires corresponding changes in llvm-gcc and clang.
llvm-svn: 56622
|
|
|
|
|
|
| |
Based on patch by Giorgos Korfiatis.
llvm-svn: 55570
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In particular, Collector was confusing to implementors. Several
thought that this compile-time class was the place to implement
their runtime GC heap. Of course, it doesn't even exist at runtime.
Specifically, the renames are:
Collector -> GCStrategy
CollectorMetadata -> GCFunctionInfo
CollectorModuleMetadata -> GCModuleInfo
CollectorRegistry -> GCRegistry
Function::getCollector -> getGC (setGC, hasGC, clearGC)
Several accessors and nested types have also been renamed to be
consistent. These changes should be obvious.
llvm-svn: 54899
|
|
|
|
|
|
| |
Please use !LLVMIsDeclaration instead.
llvm-svn: 54572
|
|
|
|
|
|
|
| |
Evan broke it in r54523 by adding a parameter in the implementation without
updating the header correspondingly.
llvm-svn: 54555
|
|
|
|
|
|
|
| |
names. This can save a lot of allocations if you aren't going to be
looking at the output.
llvm-svn: 54546
|
|
|
|
|
|
| |
failures.
llvm-svn: 53119
|
|
|
|
| |
llvm-svn: 52523
|
|
|
|
| |
llvm-svn: 51238
|
|
|
|
| |
llvm-svn: 50768
|