for example, a one-past-the-end pointer from one global variable may
be equal to the base pointer of another global variable.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@173995 91177308-0d34-0410-b5e6-96231b3b80d8
Before, the parser would assert on the following code:
@a2 = global i8 addrspace(1)* @a
@a = addrspace(1) global i8 0
because the type of @a was "i8*" instead of "i8 addrspace(1)*" when parsing
the initializer for @a2.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168197 91177308-0d34-0410-b5e6-96231b3b80d8
Previously in a vector of pointers, the pointer couldn't be any pointer type,
it had to be a pointer to an integer or floating point type. This is a hassle
for dragonegg because the GCC vectorizer happily produces vectors of pointers
where the pointer is a pointer to a struct or whatever. Vector getelementptr
was restricted to just one index, but now that vectors of pointers can have
any pointer type it is more natural to allow arbitrary vector getelementptrs.
There is however the issue of struct GEPs, where if each lane chose different
struct fields then from that point on each lane will be working down into
unrelated types. This seems like too much pain for too little gain, so when
you have a vector struct index all the elements are required to be the same.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@167828 91177308-0d34-0410-b5e6-96231b3b80d8
value but later turns out to be a function.
Unfortunately, we can't fold tests into a single file because we only get one
error out of llvm-as.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@165680 91177308-0d34-0410-b5e6-96231b3b80d8
another mechanical change accomplished though the power of terrible Perl
scripts.
I have manually switched some "s to 's to make escaping simpler.
While I started this to fix tests that aren't run in all configurations,
the massive number of tests is due to a really frustrating fragility of
our testing infrastructure: things like 'grep -v', 'not grep', and
'expected failures' can mask broken tests all too easily.
Essentially, I'm deeply disturbed that I can change the testsuite so
radically without causing any change in results for most platforms. =/
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@159547 91177308-0d34-0410-b5e6-96231b3b80d8
versions of Bash. In addition, I can back out the change to the lit
built-in shell test runner to support this.
This should fix the majority of fallout on Darwin, but I suspect there
will be a few straggling issues.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@159544 91177308-0d34-0410-b5e6-96231b3b80d8
This was done through the aid of a terrible Perl creation. I will not
paste any of the horrors here. Suffice to say, it require multiple
staged rounds of replacements, state carried between, and a few
nested-construct-parsing hacks that I'm not proud of. It happens, by
luck, to be able to deal with all the TCL-quoting patterns in evidence
in the LLVM test suite.
If anyone is maintaining large out-of-tree test trees, feel free to poke
me and I'll send you the steps I used to convert things, as well as
answer any painful questions etc. IRC works best for this type of thing
I find.
Once converted, switch the LLVM lit config to use ShTests the same as
Clang. In addition to being able to delete large amounts of Python code
from 'lit', this will also simplify the entire test suite and some of
lit's architecture.
Finally, the test suite runs 33% faster on Linux now. ;]
For my 16-hardware-thread (2x 4-core xeon e5520): 36s -> 24s
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@159525 91177308-0d34-0410-b5e6-96231b3b80d8
a pipeline, and then a positive assertion via grep, use two RUN lines
instead.
Supporting these complex ideas of 'success' and 'failure' across
multiple stages of a pipeline is brittle in the shell world, and would
block switching to ShTest format; it only worked due to contrivances
introduced by the TclTest format.
Writing this as two separate RUN lines seems clearer in any event.
This is another step toward completely removing TclTests from lit.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@159524 91177308-0d34-0410-b5e6-96231b3b80d8
This allows the user/front-end to specify a model that is better
than what LLVM would choose by default. For example, a variable
might be declared as
@x = thread_local(initialexec) global i32 42
if it will not be used in a shared library that is dlopen'ed.
If the specified model isn't supported by the target, or if LLVM can
make a better choice, a different model may be used.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@159077 91177308-0d34-0410-b5e6-96231b3b80d8
Submitted by: Anton Lokhmotov <Anton.Lokhmotov@arm.com>
Approved by: o Anton Korobeynikov
o Micah Villmow
o David Neto
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@157393 91177308-0d34-0410-b5e6-96231b3b80d8
intrinsic syntax.
Now that this is explicitly covered, I plan to upgrade the existing test
suite to use an explicit immediate. Note that I plan to specify 'true'
in most places rather than the auto-upgraded value as that is the far
more common value to end up here as that is the value coming from GCC's
builtins. The only place I'm likely to put a 'false' in is when testing
x86 which actually has different instructions for the two variants.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146369 91177308-0d34-0410-b5e6-96231b3b80d8
trampoline forms. Both of these were correct in LLVM 3.0, and we don't
need to support LLVM 2.9 and earlier in mainline.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@145174 91177308-0d34-0410-b5e6-96231b3b80d8
init.trampoline and adjust.trampoline intrinsics, into two intrinsics
like in GCC. While having one combined intrinsic is tempting, it is
not natural because typically the trampoline initialization needs to
be done in one function, and the result of adjust trampoline is needed
in a different (nested) function. To get around this llvm-gcc hacks the
nested function lowering code to insert an additional parent variable
holding the adjust.trampoline result that can be accessed from the child
function. Dragonegg doesn't have the luxury of tweaking GCC code, so it
stored the result of adjust.trampoline in the memory GCC set aside for
the trampoline itself (this is always available in the child function),
and set up some new memory (using an alloca) to hold the trampoline.
Unfortunately this breaks Go which allocates trampoline memory on the
heap and wants to use it even after the parent has exited (!). Rather
than doing even more hacks to get Go working, it seemed best to just use
two intrinsics like in GCC. Patch mostly by Sanjoy Das.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@139140 91177308-0d34-0410-b5e6-96231b3b80d8
of the instruction.
Note that this change affects the existing non-atomic load and store
instructions; the parser now accepts both forms, and the change is noted
in the release notes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@137527 91177308-0d34-0410-b5e6-96231b3b80d8
patch brings numerous advantages to LLVM. One way to look at it
is through diffstat:
109 files changed, 3005 insertions(+), 5906 deletions(-)
Removing almost 3K lines of code is a good thing. Other advantages
include:
1. Value::getType() is a simple load that can be CSE'd, not a mutating
union-find operation.
2. Types a uniqued and never move once created, defining away PATypeHolder.
3. Structs can be "named" now, and their name is part of the identity that
uniques them. This means that the compiler doesn't merge them structurally
which makes the IR much less confusing.
4. Now that there is no way to get a cycle in a type graph without a named
struct type, "upreferences" go away.
5. Type refinement is completely gone, which should make LTO much MUCH faster
in some common cases with C++ code.
6. Types are now generally immutable, so we can use "Type *" instead
"const Type *" everywhere.
Downsides of this patch are that it removes some functions from the C API,
so people using those will have to upgrade to (not yet added) new API.
"LLVM 3.0" is the right time to do this.
There are still some cleanups pending after this, this patch is large enough
as-is.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@134829 91177308-0d34-0410-b5e6-96231b3b80d8
for pre-2.9 bitcode files. We keep x86 unaligned loads, movnt, crc32, and the
target indep prefetch change.
As usual, updating the testsuite is a PITA.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@133337 91177308-0d34-0410-b5e6-96231b3b80d8
happily accept things like "sext <2 x i32> to <999 x i64>". It would
also accept "sext <2 x i32> to i64", though the verifier would catch
that later. Fixed by having castIsValid check that vector lengths match
except when doing a bitcast. (2) When creating a cast instruction, check
that the cast is valid (this was already done when creating constexpr
casts). While there, replace getScalarSizeInBits (used to allow more
vector casts) with getPrimitiveSizeInBits in getCastOpcode and isCastable
since vector to vector casts are now handled explicitly by passing to the
element types; i.e. this bit should result in no functional change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@131532 91177308-0d34-0410-b5e6-96231b3b80d8
Now that we have a first-class way to represent unaligned loads, the unaligned
load intrinsics are superfluous.
First part of <rdar://problem/8460511>.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@129401 91177308-0d34-0410-b5e6-96231b3b80d8
Add a unnamed_addr bit to global variables and functions. This will be used
to indicate that the address is not significant and therefore the constant
or function can be merged with others.
If an optimization pass can show that an address is not used, it can set this.
Examples of things that can have this set by the FE are globals created to
hold string literals and C++ constructors.
Adding unnamed_addr to a non-const global should have no effect unless
an optimization can transform that global into a constant.
Aliases are not allowed to have unnamed_addr since I couldn't figure
out any use for it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@123063 91177308-0d34-0410-b5e6-96231b3b80d8
Also add asserts that the indices are valid in InsertValueInst::init(). ExtractValueInst already asserts when constructed with invalid indices.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@120956 91177308-0d34-0410-b5e6-96231b3b80d8
it in with the SSSE3 instructions.
Steward! Could you place this chair by the aft sun deck? I'm trying to get away
from the Astors. They are such boors!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@115552 91177308-0d34-0410-b5e6-96231b3b80d8
The x86_mmx type is used for MMX intrinsics, parameters and
return values where these use MMX registers, and is also
supported in load, store, and bitcast.
Only the above operations generate MMX instructions, and optimizations
do not operate on or produce MMX intrinsics.
MMX-sized vectors <2 x i32> etc. are lowered to XMM or split into
smaller pieces. Optimizations may occur on these forms and the
result casted back to x86_mmx, provided the result feeds into a
previous existing x86_mmx operation.
The point of all this is prevent optimizations from introducing
MMX operations, which is unsafe due to the EMMS problem.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@115243 91177308-0d34-0410-b5e6-96231b3b80d8
alloca instructions (constrained by their internal encoding),
and add error checking for it. Fix an instcombine bug which
generated huge alignment values (null is infinitely aligned).
This fixes undefined behavior noticed by John Regehr.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@109643 91177308-0d34-0410-b5e6-96231b3b80d8
This patch also cleans up code that expects there to be a bitcast in the first argument and testcases that call llvm.dbg.declare.
It also strips old llvm.dbg.declare intrinsics that did not pass metadata as the first argument.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@93531 91177308-0d34-0410-b5e6-96231b3b80d8
This patch also cleans up code that expects there to be a bitcast in the first argument and testcases that call llvm.dbg.declare.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@93504 91177308-0d34-0410-b5e6-96231b3b80d8
Add another line to the ConstantExprFold test to demonstrate the GEPs may not
wrap around in either the signed or unsigned senses.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@82361 91177308-0d34-0410-b5e6-96231b3b80d8
input filename so that opt doesn't print the input filename in the
output so that grep lines in the tests don't unintentionally match
strings in the input filename.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@81537 91177308-0d34-0410-b5e6-96231b3b80d8
how to fold notionally-out-of-bounds array getelementptr indices instead
of just doing these in lib/Analysis/ConstantFolding.cpp, because it can
be done in a fairly general way without TargetData, and because not all
constants are visited by lib/Analysis/ConstantFolding.cpp. This enables
more constant folding.
Also, set the "inbounds" flag when the getelementptr indices are
one-past-the-end.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@81483 91177308-0d34-0410-b5e6-96231b3b80d8
Constant uniquing tables. This allows distinct ConstantExpr objects
with the same operation and different flags.
Even though a ConstantExpr "a + b" is either always overflowing or
never overflowing (due to being a ConstantExpr), it's still necessary
to be able to represent it both with and without overflow flags at
the same time within the IR, because the safety of the flag may
depend on the context of the use. If the constant really does overflow,
it wouldn't ever be safe to use with the flag set, however the use
may be in code that is never actually executed.
This also makes it possible to merge all the flags tests into a single test.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80998 91177308-0d34-0410-b5e6-96231b3b80d8
and unnamed numbered global variables as "@0 = global ...". Extend the
AsmParser to recognize these forms.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@78859 91177308-0d34-0410-b5e6-96231b3b80d8
There's still a strict-aliasing violation here, but I don't feel like
dealing with that right now...
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@77005 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
This only rejects mismatches between target specific calling convention
and C/LLVM specific calling convention.
There are too many fastcc/C, coldcc/cc42 mismatches in the testsuite, these are
not reject by the verifier.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@72248 91177308-0d34-0410-b5e6-96231b3b80d8
Path.cpp:59: warning: case label value exceeds maximum value for type
magic[0] is a (signed) char, but some case values are unsigned (e.g. 0xde).
When magic[0] was 0xde, the switch has taken the default branch instead of case
0xde branch.
Apparently this was the behaviour with older versions of gcc too, but not with g++.
Now g++-4.4 behaves as gcc, and ignores unsigned case values out of range signed
range.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@70038 91177308-0d34-0410-b5e6-96231b3b80d8
call, we should treat "i64 zext" as the start of a constant expr, but
"i64 0 zext" as an argument with an obsolete attribute on it (this form
is already tested by test/Assembler/2007-07-30-AutoUpgradeZextSext.ll).
Make the autoupgrade logic more discerning to avoid treating "i64 zext"
as an old-style attribute, causing us to reject a valid constant expr.
This fixes PR3876.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@67682 91177308-0d34-0410-b5e6-96231b3b80d8
shift constant expressions, and add support for folding vector
shift constant expressions. This fixes PR3802.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@67010 91177308-0d34-0410-b5e6-96231b3b80d8
stripped .bc file, it didn't make any attempt to try to reuse anonymous types.
This causes an amazing type explosion due to types getting duplicated everywhere
they are referenced and other problems.
This also caused correctness issues, because opaque types are unique for each time
they are uttered in the file. This means that stripping a .bc file could produce
a .ll file that could not be assembled (e.g. 2009-02-28-StripOpaqueName.ll).
This patch fixes both of these issues.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@65738 91177308-0d34-0410-b5e6-96231b3b80d8
and clean recursive descent parser.
This change has a couple of ramifications:
1. The parser code is about 400 lines shorter (in what we maintain, not
including what is autogenerated).
2. The code should be significantly faster than the old code because we
don't have to work around bison's poor handling of datatypes with
ctors/dtors. This also makes the code much more resistant to memory
leaks.
3. We now get caret diagnostics from the .ll parser, woo.
4. The actual diagnostics emited from the parser are completely different
so a bunch of testcases had to be updated.
5. I now disallow "%ty = type opaque %ty = type i32". There was no good
reason to support this, it was just an accident of the old
implementation. I have no reason to think that anyone is actually using
this.
6. The syntax for sticking a global variable has changed to make it
unambiguous. I don't think anyone is depending on this since only clang
supports this and it is not solid yet, so I'm not worried about anything
breaking.
7. This gets rid of the last use of bison, and along with it the .cvs files.
I'll prune this from the makefiles as a subsequent commit.
There are a few minor cleanups that can be done after this commit (suggestions
welcome!) but this passes dejagnu testing and is ready for its time in the
limelight.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@61558 91177308-0d34-0410-b5e6-96231b3b80d8
integer type. Invalid things like 'float 42' are now rejected by the
semantic analysis in the productions not the parser. This fixes PR2733.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@57560 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
cases quoting of <{ didn't work out, so I changed the grep to check for }>
instead.
This fixes 7 testcases that were not properly running before.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@52182 91177308-0d34-0410-b5e6-96231b3b80d8
don't fail when (expected) error output is produced. This fixes 17 tests.
While I was there, I also made all RUN lines of the form "not llvm-as..." a bit
more consistent, they now all redirect stderr and stdout to /dev/null and use
input redirect to read their input.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@52174 91177308-0d34-0410-b5e6-96231b3b80d8
types on functions, with adjustments so that it accepts both
new-style aggregate returns and old-style MRV returns, including those
with only a single member.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@52157 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
and bitcode support for the extractvalue and insertvalue
instructions and constant expressions.
Note that this does not yet include CodeGen support.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@51468 91177308-0d34-0410-b5e6-96231b3b80d8
regions of memory that have a target specific relationship, as described in the
Embedded C Technical Report.
This also implements the 2007-12-11-AddressSpaces test,
which demonstrates how address space attributes can be used in LLVM IR.
In addition, this patch changes the bitcode signature for stores (in a backwards
compatible manner), such that the pointer type, rather than the pointee type, is
encoded. This permits type information in the pointer (e.g. address space) to be
preserved for stores.
LangRef updates are forthcoming.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@44858 91177308-0d34-0410-b5e6-96231b3b80d8
Reimplement the xform in Analysis/ConstantFolding.cpp where we can use
targetdata to validate that it is safe. While I'm in there, fix some const
correctness issues and generalize the interface to the "operand folder".
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@44817 91177308-0d34-0410-b5e6-96231b3b80d8
methods are new to Function:
bool hasCollector() const;
const std::string &getCollector() const;
void setCollector(const std::string &);
void clearCollector();
The assembly representation is as such:
define void @f() gc "shadow-stack" { ...
The implementation uses an on-the-side table to map Functions to
collector names, such that there is no overhead. A StringPool is
further used to unique collector names, which are extremely
likely to be unique per process.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@44769 91177308-0d34-0410-b5e6-96231b3b80d8
the function type, instead they belong to functions
and function calls. This is an updated and slightly
corrected version of Reid Spencer's original patch.
The only known problem is that auto-upgrading of
bitcode files doesn't seem to work properly (see
test/Bitcode/AutoUpgradeIntrinsics.ll). Hopefully
a bitcode guru (who might that be? :) ) will fix it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@44359 91177308-0d34-0410-b5e6-96231b3b80d8
This also changes the syntax for llvm.bswap, llvm.part.set, llvm.part.select, and llvm.ct* intrinsics. They are automatically upgraded by both the LLVM ASM reader and the bitcode reader. The test cases have been updated, with special tests added to ensure the automatic upgrading is supported.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@40807 91177308-0d34-0410-b5e6-96231b3b80d8
Make the AsmParser auto-upgrade the old zext and sext
keywords for parameter attributes and handle the
end-of-line ambiguity.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@40610 91177308-0d34-0410-b5e6-96231b3b80d8
Change the keywords for the zext and sext parameter attributes to be
zeroext and signext so they don't conflict with the keywords for the
instructions of the same name. This gets around the ambiguity.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@40069 91177308-0d34-0410-b5e6-96231b3b80d8
Make ParamAttrsList objects unique. You can no longer directly create or
destroy them but instead must go through the ParamAttrsList::get()
interface.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@36327 91177308-0d34-0410-b5e6-96231b3b80d8
Remove && from the end of the lines to prevent tests from throwing run
lines into the background. Also, clean up places where the same command
is run multiple times by using a temporary file.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@36142 91177308-0d34-0410-b5e6-96231b3b80d8
