| Age | Commit message (Collapse) | Author |
|---|
|
contexts through a number of APIs.
llvm-svn: 78258
|
|
This fixes PR4666.
llvm-svn: 78056
|
|
llvm-svn: 77733
|
|
change back are
metadata related, which I'm waiting on to avoid conflicting with Devang.
llvm-svn: 77721
|
|
llvm-svn: 77635
|
|
llvm-svn: 77517
|
|
llvm-svn: 77516
|
|
llvm-svn: 77494
|
|
New name is Metadata.h.
llvm-svn: 77370
|
|
llvm-svn: 77366
|
|
llvm-svn: 77347
|
|
llvm-svn: 77266
|
|
LangRef.html changes for details.
llvm-svn: 77259
|
|
llvm-svn: 77247
|
|
llvm-svn: 77100
|
|
llvm-svn: 77051
|
|
llvm-svn: 77044
|
|
thanks to contexts-on-types. More to come.
llvm-svn: 77011
|
|
- Rename member function size(). New name is length().
- Store string beginning and length. Earlier it used to store string end.
llvm-svn: 76841
|
|
METADATA_BLOCK in bitcode file.
llvm-svn: 76834
|
|
Derive MDString directly from MetadataBase.
Introduce new bitcode block to hold metadata.
llvm-svn: 76759
|
|
exact sdiv flags.
llvm-svn: 76475
|
|
"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
|
|
AllocaInst and MallocInst.
llvm-svn: 75863
|
|
llvm-svn: 75703
|
|
the [I|F]CmpInst constructors. Who knew!?
llvm-svn: 75200
|
|
module is required.
llvm-svn: 75025
|
|
these instructions, no autoupgrade or backwards compatibility support is
provided.
llvm-svn: 74991
|
|
llvm-svn: 74985
|
|
llvm-svn: 74942
|
|
llvm-svn: 74881
|
|
the last time, for the
moment, that I will need to make far-reaching changes.
llvm-svn: 74655
|
|
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
|
|
The problem was that BitcodeReader::materializeModule would read functions
from the bc file in densemap pointer key order (doubly non-deterministic!),
which would cause the use-def chains to be set up for globals in
non-determinstic order. Non-determinstic use/def chains can cause
nondeterminism in many places down-stream.
Many thanks to Julien Lerouge for putting together the pass in the PR that
shows the issue!
llvm-svn: 73470
|
|
integer and floating-point opcodes, introducing
FAdd, FSub, and FMul.
For now, the AsmParser, BitcodeReader, and IRBuilder all preserve
backwards compatability, and the Core LLVM APIs preserve backwards
compatibility for IR producers. Most front-ends won't need to change
immediately.
This implements the first step of the plan outlined here:
http://nondot.org/sabre/LLVMNotes/IntegerOverflow.txt
llvm-svn: 72897
|
|
metadata references non-Constant values such as instructions.
llvm-svn: 72685
|
|
llvm-svn: 72659
|
|
llvm-svn: 72610
|
|
Constant* in preperation of a future change to support holding non-Constants
in an MDNode.
llvm-svn: 71407
|
|
state out of the BitstreamReader class into a BitstreamCursor class.
Doing this allows the client to have multiple cursors into the same
file, each with potentially different live block stacks and
abbreviation records.
llvm-svn: 70157
|
|
to support C99 inline, GNU extern inline, etc. Related bugzilla's
include PR3517, PR3100, & PR2933. Nothing uses this yet, but it
appears to work.
llvm-svn: 68940
|
|
llvm-svn: 68458
|
|
Constant, MDString and MDNode which can only be used by globals with a name
that starts with "llvm." or as arguments to a function with the same naming
restriction.
llvm-svn: 68420
|
|
llvm-svn: 68173
|
|
it be an LLVM IR User object.
llvm-svn: 68156
|
|
same as a normal i80 {low64, high16} rather
than its own {high64, low16}. A depressing number
of places know about this; I think I got them all.
Bitcode readers and writers convert back to the old
form to avoid breaking compatibility.
llvm-svn: 67562
|
|
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
|
