call sites as tail calls unconditionally.  While it's theoretically true that
this is just an optimization, it's an optimization that we very much want to
happen even at -O0, or else ARC applications become substantially harder to
debug.  See r169796 for the llvm/fast-isel side of things.
rdar://12553082

llvm-svn: 169996

llvm/Target/TargetMachine.h will not provide "llvm/TargetTransformInfo.h" any more.

llvm-svn: 169816

This prevents the functions generated by that pass from using the red zone.
<rdar://problem/12843084>

llvm-svn: 169755

llvm-svn: 169713

Note that there is no test suite update. This was found by a couple of
tests failing when the test suite was run on a powerpc64 host (thanks
Roman!). The tests don't specify a triple, which might seem surprising
for a codegen test. But in fact, these tests don't even inspect their
output. Not at all. I could add a bunch of triples to these tests so
that we'd get the test coverage for normal builds, but really someone
needs to go through and add actual *tests* to these tests. =[ The ones
in question are:

  test/CodeGen/bitfield-init.c
  test/CodeGen/union.c

llvm-svn: 169694

This was an egregious bug due to the several iterations of refactorings
that took place. Size no longer meant what it original did by the time
I finished, but this line of code never got updated. Unfortunately we
had essentially zero tests for this in the regression test suite. =[

I've added a PPC64 run over the bitfield test case I've been primarily
using. I'm still looking at adding more tests and making sure this is
the *correct* bitfield access code on PPC64 linux, but it looks pretty
close to me, and it is *worlds* better than before this patch as it no
longer asserts! =] More commits to follow with at least additional tests
and maybe more fixes.

Sorry for the long breakage due to this....

llvm-svn: 169691

llvm-svn: 169652

We were emitting calls to blocks as if all arguments were
required --- i.e. with signature (A,B,C,D,...) rather than
(A,B,...).  This patch fixes that and accounts for the
implicit block-context argument as a required argument.
In addition, this patch changes the function type under which
we call unprototyped functions on platforms like x86-64 that
guarantee compatibility of variadic functions with unprototyped
function types;  previously we would always call such functions
under the LLVM type T (...)*, but now we will call them under
the type T (A,B,C,D,...)*.  This last change should have no
material effect except for making the type conventions more
explicit;  it was a side-effect of the most convenient implementation.

llvm-svn: 169588

generally support the C++11 memory model requirements for bitfield
accesses by relying more heavily on LLVM's memory model.

The primary change this introduces is to move from a manually aligned
and strided access pattern across the bits of the bitfield to a much
simpler lump access of all bits in the bitfield followed by math to
extract the bits relevant for the particular field.

This simplifies the code significantly, but relies on LLVM to
intelligently lowering these integers.

I have tested LLVM's lowering both synthetically and in benchmarks. The
lowering appears to be functional, and there are no really significant
performance regressions. Different code patterns accessing bitfields
will vary in how this impacts them. The only real regressions I'm seeing
are a few patterns where the LLVM code generation for loads that feed
directly into a mask operation don't take advantage of the x86 ability
to do a smaller load and a cheap zero-extension. This doesn't regress
any benchmark in the nightly test suite on my box past the noise
threshold, but my box is quite noisy. I'll be watching the LNT numbers,
and will look into further improvements to the LLVM lowering as needed.

llvm-svn: 169489

The count attribute is more accurate with regards to the size of an array. It
also obviates the upper bound attribute in the subrange. We can also better
handle an unbound array by setting the count to -1 instead of the lower bound to
1 and upper bound to 0.

llvm-svn: 169311

in the triple.

llvm-svn: 169292

after the fixed size block header when generating
captured block variable info. // rdar://12773256

llvm-svn: 169285

uncovered.

This required manually correcting all of the incorrect main-module
headers I could find, and running the new llvm/utils/sort_includes.py
script over the files.

I also manually added quite a few missing headers that were uncovered by
shuffling the order or moving headers up to be main-module-headers.

llvm-svn: 169237

The count field is necessary because there isn't a difference between the 'lo'
and 'hi' attributes for a one-element array and a zero-element array. When the
count is '0', we know that this is a zero-element array. When it's >=1, then
it's a normal constant sized array. When it's -1, then the array is unbounded.

llvm-svn: 169219

Have clang use LLVM IR's fast-math flags when in FastMath or FiniteMathOnly modes. Test cases included.

llvm-svn: 169191

llvm-svn: 169187

after its lifetime has ended!

llvm-svn: 169170

Add Clang flags -fsanitize-blacklist and -fno-sanitize-blacklist. Make this flag usable for ASan. Blacklisting can be used to disable sanitizer checks for particular file/function/object.

llvm-svn: 169144

llvm-svn: 169138

llvm-svn: 169124

llvm-svn: 169114

Pull the Attr iteration parts out of Attr.h, so including DeclBase.h doesn't pull in all the generated Attr code.

Required to pull some functions out of line, but this shouldn't have a perf impact.
No functionality change.

llvm-svn: 169092

llvm-svn: 169041

llvm-svn: 169037

llvm-svn: 168959

1) init-order sanitizer: initialization-order checker.
Status: usable, but may produce false positives w/o proper blacklisting.
2) use-after-return sanitizer
Status: implemented, but heavily understed.
Should be optional, as it significanlty slows program down.
3) use-after-scope sanitizer
Status: in progress.

llvm-svn: 168950

Among other differences, GCC accepts

  typedef int IA[];
  typedef int A10[10];
  static A10 *f(void);
  static IA  *f(void);
  void g(void) {
    (void)sizeof(*f());
  }

but clang used to reject it with:

  invalid application of 'sizeof' to an incomplete type 'IA' (aka 'int []')

The intention of c99's 6.2.7 seems to be that we should use the composite type
and accept as gcc does.

Doing the type merging required some extra fixes:
  * Use the type from the function type in initializations, even if an parameter
    is available.
  * Fix the merging of the noreturn attribute in function types.
  * Make CodeGen  handle the fact that an parameter type can be different from
    the corresponding type in the function type.

llvm-svn: 168895

in deciding a copy/dispose field is needed in a byref structure
and when generating the copy/dispose helpers. In certain
cases, these fields were being added but no copy/dispose was
being generated. This was uncovered in ARC, but not in MRR.
// rdar://12759433

llvm-svn: 168825

rdar://12723368

llvm-svn: 168821

the original parameter or return type.

Since we do not accurately represent the data fields of a union, we should not
directly load or store a union type.

As an exmple, if we have i8,i8, i32, i32 as one field type and i32,i32 as
another field type, the first field type will be chosen to represent the union.
If we load with the union's type, the 3rd byte and the 4th byte will be skipped.

rdar://12723368

llvm-svn: 168820

llvm-svn: 168782

objc_loadWeak. This retains and autorelease the weakly-refereced
object. This hidden autorelease sometimes makes __weak variable alive even
after the weak reference is erased, because the object is still referenced
by an autorelease pool. This patch overcomes this behavior by loading a 
weak object via call to objc_loadWeakRetained(), followng it by objc_release
at appropriate place, thereby removing the hidden autorelease. // rdar://10849570

llvm-svn: 168740

Introduces new sanitizer "unsigned-integer-overflow".

llvm-svn: 168701

ELF ABI.

Complex values are to be passed in registers as though the real and
imaginary parts were passed as separate parameters.  Prior to this
patch, complex values were passed as byval aggregates.  It turns out
that specifying getDirect() for all complex types when classifying the
argument type results in the desired behavior.

The new Clang test case verifies that the correct LLVM IR is generated
for caller and callee for each of the underlying types for _Complex.

llvm-svn: 168673

MSPGCC renamed ISR vectors from vector_<address> to __isr_<number>. This patch makes Clang reflect this scheme.
Patch by Job Noorman!

llvm-svn: 168598

llvm-svn: 168510

llvm-svn: 168355

Also fixes a bit/byte mismatch when checking if a target supports atomic ops of a certain size.

llvm-svn: 168260

Separate out the notions of 'has a trivial special member' and 'has a
non-trivial special member', and use them appropriately. These are not
opposites of one another (there might be no special member, or in C++11 there
might be a trivial one and a non-trivial one). The CXXRecordDecl predicates
continue to produce incorrect results, but do so in fewer cases now, and
they document the cases where they might be wrong.

No functionality changes are intended here (they will come when the predicates
start producing the right answers...).

llvm-svn: 168119

Make sure CodeGenTypes correctly reconverts function types.  Fixes PR14355, a crash in IR generation.

llvm-svn: 168112