Age | Commit message (Collapse) | Author |
|
these instructions, no autoupgrade or backwards compatibility support is
provided.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@74991 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@74985 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@74942 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@74881 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
the last time, for the
moment, that I will need to make far-reaching changes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@74655 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@74640 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@74614 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@73470 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@72897 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
metadata references non-Constant values such as instructions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@72685 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@72659 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@72610 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Constant* in preperation of a future change to support holding non-Constants
in an MDNode.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@71407 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@70157 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
to support C99 inline, GNU extern inline, etc. Related bugzilla's
include PR3517, PR3100, & PR2933. Nothing uses this yet, but it
appears to work.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@68940 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@68458 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@68420 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@68173 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
it be an LLVM IR User object.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@68156 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@67562 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
linkage, so remove it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@66690 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
linkage: this linkage type only applies to declarations,
but ODR is only relevant to globals with definitions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@66650 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@66339 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
equal to the
type of the vectors being shuffled.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@64401 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
the index of the value being extracted is always an i32. This fixes PR3465
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@63597 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@62279 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@61240 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
builds.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@61094 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
callee will not introduce any new aliases of that pointer.
The attributes had all bits allocated already, so I decided to collapse
alignment. Alignment was previously stored as a 16-bit integer from bits 16 to
32 of the attribute, but it was required to be a power of 2. Now it's stored in
log2 encoded form in five bits from 16 to 21. That gives us 11 more bits of
space.
You may have already noticed that you only need four bits to encode a 16-bit
power of two, so why five bits? Because the AsmParser accepted 32-bit
alignments, even though we couldn't store them (they were silently discarded).
Now we can store them in memory, but not in the bitcode.
The bitcode format was already storing these as 64-bit VBR integers. So, the
bitcode format stays the same, keeping the alignment values stored as 16 bit
raw values. There's some hideous code in the reader and writer that deals with
this, waiting to be ripped out the moment we run out of bits again and have to
replace the parameter attributes table encoding.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@61019 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
<result> = shufflevector <n x <ty>> <v1>, <n x <ty>> <v2>, <m x i32> <mask>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@58964 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
and actually work. We can now read the llvm 2.3 bc file from PR2849
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@57122 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
- return attributes - inreg, zext and sext
- parameter attributes
- function attributes - nounwind, readonly, readnone, noreturn
Return attributes use 0 as the index.
Function attributes use ~0U as the index.
This patch requires corresponding changes in llvm-gcc and clang.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@56704 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@56622 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@56535 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Function Notes also. Function notes are stored at index ~0.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@56511 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
bitcode reader/writer as follows:
- add and use new bitcode FUNC_CODE_INST_VSELECT to handle the llvm
select opcode using either i1 or [N x i1] as the selector.
- retain old BITCODE FUNC_CODE_INST_SELECT in the bitcode reader to
handle select on i1 for backwards compatibility with existing bitcode
files.
- re-enable the vector-select.ll test program.
Also, rename the recently added bitcode opcode FUNC_CODE_INST_VCMP to
FUNC_CODE_INST_CMP2 and make the bitcode writer use it to handle
fcmp/icmp on scalars or vectors. In the bitcode writer, use
FUNC_CODE_INST_CMP for vfcmp/vicmp only. In the bitcode reader, have
FUNC_CODE_INST_CMP handle icmp/fcmp returning bool, for backwards
compatibility with existing bitcode files.
Patch by Preston Gurd!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@56233 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
way it handles the type of the condition is breaking plain
scalar select in the case that the value is a
forward-reference.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@55976 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
and, if so, to return a vector of boolean as a result;
Extend the select LLVM IR instruction to allow you to specify a result
type which is a vector of boolean, in which case the result will be an
element-wise selection instead of choosing one vector or the other; and
Update LangRef.html to describe these changes.
This patch was contributed by Preston Gurd!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@55969 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@55657 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
operands.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@55127 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
people want fast *and* correct. Sheesh.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@55102 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
- Postgres
- llvm-test/SingleSource/UnitTests/{2006-01-23-InitializedBitField,
2004-11-28-GlobalBoolLayout, 2003-05-02-DependentPHI}
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@55100 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
this speeds up the bcreader from 6.67s to 0.12s on a testcase Daniel
provided. rdar://6158117
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@55090 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@54899 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Remove the GetResultInst instruction. It is still accepted in LLVM assembly
and bitcode, where it is now auto-upgraded to ExtractValueInst. Also, remove
support for return instructions with multiple values. These are auto-upgraded
to use InsertValueInst instructions.
The IRBuilder still accepts multiple-value returns, and auto-upgrades them
to InsertValueInst instructions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@53941 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
folded. Remove code that handled the case where they aren't
folded, and remove bitcode reader/writer support for them.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@53887 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
bc files for modules with a target triple that indicates they are for
darwin. The reader unconditionally handles this, and the writer could
turn this on for more targets if we care.
This change has two benefits for darwin:
1) it allows us to encode the cpu type of the file in an easy to read
place that doesn't require decoding the bc file.
2) it works around a bug (IMO) in darwin's AR where it is incapable of
handling files that are not a multiple of 8 bytes long. BC files
are only guaranteed to be multiples of 4 bytes long.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@53275 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@51822 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
insertvalue and extractvalue to use constant indices instead of
Value* indices. And begin updating LangRef.html.
There's definately more to come here, but I'm checking this
basic support in now to make it available to people who are
interested.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@51806 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@51570 91177308-0d34-0410-b5e6-96231b3b80d8
|