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
