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
code hints that it would be a good idea to inline
a function ("inline" keyword). No functional change
yet; FEs do not emit this and inliner does not use it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80063 91177308-0d34-0410-b5e6-96231b3b80d8
This change speeds up llvm-gcc by more then 6% at "-O0 -g" (measured by compiling InstructionCombining.cpp!)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79977 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
- Rename member function size(). New name is length().
- Store string beginning and length. Earlier it used to store string end.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@76841 91177308-0d34-0410-b5e6-96231b3b80d8
"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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@76385 91177308-0d34-0410-b5e6-96231b3b80d8
This adds location info for all llvm_unreachable calls (which is a macro now) in
!NDEBUG builds.
In NDEBUG builds location info and the message is off (it only prints
"UREACHABLE executed").
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@75640 91177308-0d34-0410-b5e6-96231b3b80d8
Make llvm_unreachable take an optional string, thus moving the cerr<< out of
line.
LLVM_UNREACHABLE is now a simple wrapper that makes the message go away for
NDEBUG builds.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@75379 91177308-0d34-0410-b5e6-96231b3b80d8
U include/llvm/LLVMContext.h
U lib/VMCore/LLVMContext.cpp
U lib/AsmParser/LLParser.cpp
U lib/AsmParser/LLParser.h
Temporarily reverting r74648. It was causing massive failures in release mode.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@74653 91177308-0d34-0410-b5e6-96231b3b80d8
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
Also create isValidElementType for ArrayType, PointerType, StructType and
VectorType.
Make LLParser use them. This closes up some holes like an assertion failure on:
%x = type {label}
but largely doesn't change any semantics. The only thing we accept now which
we didn't before is vectors of opaque type such as "<4 x opaque>". The opaque
can be resolved to an int or float when linking.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@73016 91177308-0d34-0410-b5e6-96231b3b80d8
Update code generator to use this attribute and remove NoImplicitFloat target option.
Update llc to set this attribute when -no-implicit-float command line option is used.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@72959 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
Update code generator to use this attribute and remove DisableRedZone target option.
Update llc to set this attribute when -disable-red-zone command line option is used.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@72894 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
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
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
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: 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
validate an invariant so that the asmparser rejects a bad construct
instead of the verifier. Before:
llvm-as: assembly parsed, but does not verify as correct!
Invalid struct return type!
i64 (%struct.Type*, %struct.Type*)* @foo
after:
llvm-as: t.ll:5:8: functions with 'sret' argument must return void
define i64 @foo(%struct.Type* noalias nocapture sret %agg.result, %struct.Type* nocapture byval %t) nounwind {
^
Second, check that void is only used where allowed (in function return types) not in
arbitrary places, fixing PR3747 - Crash in llvm-as with void field in struct. We
now reject that example with:
$ llvm-as t.ll
llvm-as: t.ll:1:12: struct element can not have void type
%x = type {void}
^
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@66394 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
llvm-as: t.ll:2:15: pointers to void are invalid, use i8* instead
%X = type void*
^
instead of asserting and dying.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@64089 91177308-0d34-0410-b5e6-96231b3b80d8
target directories themselves. This also means that VMCore no longer
needs to know about every target's list of intrinsics. Future work
will include converting the PowerPC target to this interface as an
example implementation.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@63765 91177308-0d34-0410-b5e6-96231b3b80d8
llvm-as: crash11.ll:2:27: function may not return return opaque type
"xw" = tail call opaque @608(label %31)
^
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@61722 91177308-0d34-0410-b5e6-96231b3b80d8
llvm-as: crash10.ll:3:35: floating point constant does not have type 'ppc_fp128'
"dumy" = fcmp ult ppc_fp128 "j",9209.4
^
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@61721 91177308-0d34-0410-b5e6-96231b3b80d8
llvm-as: crash07.ll:2:32: va_arg requires operand with first class type
%y = va_arg [52 x <{}>] %43, double (...) sspreq
^
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@61683 91177308-0d34-0410-b5e6-96231b3b80d8
just be removed. However, this fixes PR3281:crash04.ll, diagnosing it with:
lvm-as: crash04.ll:2:13: vfcmp requires vector floating point operands
vfcmp uno double* undef, undef
^
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@61680 91177308-0d34-0410-b5e6-96231b3b80d8
ParseAssemblyString with a specified module would not parse
into the module, it would create and return a new one.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@61635 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
alignment attribute such that 0 means unaligned.
This will probably require a rebuild of llvm-gcc because of the change to
Attributes.h. If you see many test failures on "make check", please rebuild
your llvm-gcc.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@61030 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
