More objc gc work. Match gcc's treatment of ivar access
true a local pointer to objective-c object in generating
write barriers.

llvm-svn: 65290

local array of objects are non-gc'able.

llvm-svn: 65251

Handle case of none gc'able objects regardless of their
type.

llvm-svn: 65205

Shorten; no functionality change.

llvm-svn: 65145

Set call attribute for direct calls (i.e. noreturn).
- Remove an unused variant of EmitCallExpr overload.

llvm-svn: 65130

More objc gc's ir-gen fixes.

llvm-svn: 65097

More objc's gc ir-gen stuff.

llvm-svn: 65077

Generate the conservative objc gc's API for now.

llvm-svn: 65051

Some code simplification. ir gen for gc'able array
of objects in objc.

llvm-svn: 64992

Address Chris's comments regarding C++ name mangling.

llvm-svn: 64984

Some refactoring and simplificaiotn of objc's gc
ir gen.

llvm-svn: 64954

Start generating gc'able code using the new
objc gc type attributes.

llvm-svn: 64935

Cleanup objc's gc attributes code no longer needed.
This make warn-weak-field.m to fail (subject of
a followup patch).
attr-objc-gc.m no passes.

llvm-svn: 64925

80-cols.

llvm-svn: 64779

Support IRgen of sqrt -> llvm.sqrt, pow -> llvm.pow.

- Define pow[lf]?, sqrt[lf]? as builtins.

- Add -fmath-errno option which binds to LangOptions.MathErrno

- Add new builtin flag Builtin::Con

Support IRgen of sqrt -> llvm.sqrt, pow -> llvm.pow.

- Define pow[lf]?, sqrt[lf]? as builtins.

- Add -fmath-errno option which binds to LangOptions.MathErrno

- Add new builtin flag Builtin::Context::isConstWithoutErrno for
functions which can be marked as const if errno isn't respected for
math functions. Sema automatically marks these functions as const
when they are defined, if MathErrno=0.

- IRgen uses const attribute on sqrt and pow library functions to
decide if it can use the llvm intrinsic.

llvm-svn: 64689

show more ...

fix volatile handling with ExtVectorElementExpr, so that we
emit two volatile loads for:
typedef __attribute__(( ext_vector_type(4) )) float float4;

float test(volatile float4 *P) {
return P->x+P-

fix volatile handling with ExtVectorElementExpr, so that we
emit two volatile loads for:
typedef __attribute__(( ext_vector_type(4) )) float float4;

float test(volatile float4 *P) {
return P->x+P->y;
}

llvm-svn: 64683

show more ...

introduce and use a new ExtVectorElementExpr::isArrow method, at Eli's suggestion

llvm-svn: 64681

enhance ExtVectorElementExpr to allow V->xxyy to work like (*V).xxyy

llvm-svn: 64667

Add hook to add attributes to function declarations that we know
about, whether they are builtins or not. Use this to add the
appropriate "format" attribute to NSLog, NSLogv, asprintf, and
vasprintf,

Add hook to add attributes to function declarations that we know
about, whether they are builtins or not. Use this to add the
appropriate "format" attribute to NSLog, NSLogv, asprintf, and
vasprintf, and to translate builtin attributes (from Builtins.def)
into actual attributes on the function declaration.

Use the "printf" format attribute on function declarations to
determine whether we should do format string checking, rather than
looking at an ad hoc list of builtins and "known" function names.

Be a bit more careful about when we consider a function a "builtin" in
C++.

llvm-svn: 64561

show more ...

Implicitly declare certain C library functions (malloc, strcpy, memmove,
etc.) when we perform name lookup on them. This ensures that we
produce the correct signature for these functions, which has t

Implicitly declare certain C library functions (malloc, strcpy, memmove,
etc.) when we perform name lookup on them. This ensures that we
produce the correct signature for these functions, which has two
practical impacts:

1) When we're supporting the "implicit function declaration" feature
of C99, these functions will be implicitly declared with the right
signature rather than as a function returning "int" with no
prototype. See PR3541 for the reason why this is important (hint:
GCC always predeclares these functions).

2) If users attempt to redeclare one of these library functions with
an incompatible signature, we produce a hard error.

This patch does a little bit of work to give reasonable error
messages. For example, when we hit case #1 we complain that we're
implicitly declaring this function with a specific signature, and then
we give a note that asks the user to include the appropriate header
(e.g., "please include <stdlib.h> or explicitly declare 'malloc'"). In
case #2, we show the type of the implicit builtin that was incorrectly
declared, so the user can see the problem. We could do better here:
for example, when displaying this latter error message we say
something like:

'strcpy' was implicitly declared here with type 'char *(char *, char
const *)'

but we should really print out a fake code line showing the
declaration, like this:

'strcpy' was implicitly declared here as:

char *strcpy(char *, char const *)

This would also be good for printing built-in candidates with C++
operator overloading.

The set of C library functions supported by this patch includes all
functions from the C99 specification's <stdlib.h> and <string.h> that
(a) are predefined by GCC and (b) have signatures that could cause
codegen issues if they are treated as functions with no prototype
returning and int. Future work could extend this set of functions to
other C library functions that we know about.

llvm-svn: 64504

show more ...

Add basic support for C++ name mangling according to the Itanium C++
ABI to the CodeGen library. Since C++ code-generation is so
incomplete, we can't exercise much of this mangling code. However, a
f

Add basic support for C++ name mangling according to the Itanium C++
ABI to the CodeGen library. Since C++ code-generation is so
incomplete, we can't exercise much of this mangling code. However, a
few smoke tests show that it's doing the same thing as GCC. When C++
codegen matures, we'll extend the ABI tester to verify name-mangling
as well, and complete the implementation here.

At this point, the major client of name mangling is in the uses of the
new "overloadable" attribute in C, which allows overloading. Any
"overloadable" function in C (or in an extern "C" block in C++) will
be mangled the same way that the corresponding C++ function would be
mangled.

llvm-svn: 64413

show more ...

Add support for generating block call expressions.

llvm-svn: 64346

Support IRgen of va_arg of structure as l-value.

llvm-svn: 64325

Some refactoring of Ivar offset code gen.
in preparation for nonfragile ivar offset work.

llvm-svn: 64225

Add util Emit{LoadOf,StoreTo}Scalar methods to encapsulate conversion
from LLVM memory type to/from LLVM temporary type.
- No intended functionality change.

llvm-svn: 64191