| Commit message (Collapse) | Author | Age | Files | Lines | 
| ... |  | 
| | 
| 
| 
| 
| 
|  | 
copy-in of c++ class objects into blocks.
llvm-svn: 105622
 | 
| | 
| 
| 
| 
| 
|  | 
pointer. Original patch by Troy D. Straszheim; fixes PR7283.
llvm-svn: 105621
 | 
| | 
| 
| 
|  | 
llvm-svn: 105620
 | 
| | 
| 
| 
|  | 
llvm-svn: 105619
 | 
| | 
| 
| 
|  | 
llvm-svn: 105618
 | 
| | 
| 
| 
|  | 
llvm-svn: 105617
 | 
| | 
| 
| 
| 
| 
|  | 
even/odd, since adjacent changes are more likely to be related.
llvm-svn: 105613
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
top of the standard 'delta debugging' algorithm.
 - This can give substantial speedups in the delta process for inputs we can construct dependency information for.
llvm-svn: 105612
 | 
| | 
| 
| 
| 
| 
|  | 
need to go past the highest offset that's known to contain an empty base subobject.
llvm-svn: 105611
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
the llvm tests :-(
It was failing with
-- Testing: 5324 tests, 8 threads --
Fatal Python error: PyEval_AcquireThread: NULL new thread state
llvm-svn: 105610
 | 
| | 
| 
| 
|  | 
llvm-svn: 105608
 | 
| | 
| 
| 
|  | 
llvm-svn: 105607
 | 
| | 
| 
| 
|  | 
llvm-svn: 105606
 | 
| | 
| 
| 
| 
| 
| 
|  | 
realloc implementation can try to expand the allocated memory block in-place,
avoiding the copy.
llvm-svn: 105605
 | 
| | 
| 
| 
|  | 
llvm-svn: 105604
 | 
| | 
| 
| 
| 
| 
|  | 
the function call is left where the local variable is declared.
llvm-svn: 105602
 | 
| | 
| 
| 
| 
| 
| 
|  | 
Discussed here:
http://lists.cs.uiuc.edu/pipermail/llvmdev/2010-June/032107.html
llvm-svn: 105601
 | 
| | 
| 
| 
|  | 
llvm-svn: 105600
 | 
| | 
| 
| 
| 
| 
|  | 
make it through codegen to the .s file
llvm-svn: 105599
 | 
| | 
| 
| 
| 
| 
|  | 
save some c++ code in CGBuiltins.
llvm-svn: 105598
 | 
| | 
| 
| 
|  | 
llvm-svn: 105597
 | 
| | 
| 
| 
|  | 
llvm-svn: 105596
 | 
| | 
| 
| 
|  | 
llvm-svn: 105595
 | 
| | 
| 
| 
|  | 
llvm-svn: 105594
 | 
| | 
| 
| 
| 
| 
|  | 
appropriate to check them when compiling or other archs.  Fixes a problem where compiling for NEON would use x86 sema rules.
llvm-svn: 105593
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
ARM.
Fixes PR7310.
llvm-svn: 105592
 | 
| | 
| 
| 
|  | 
llvm-svn: 105591
 | 
| | 
| 
| 
|  | 
llvm-svn: 105590
 | 
| | 
| 
| 
| 
| 
|  | 
shufflevector instruction.  This means it can now be used for vector truncation and concatenation.  This will be used for the ARM NEON implementation.
llvm-svn: 105589
 | 
| | 
| 
| 
| 
| 
| 
|  | 
fix vcvt naming
handle vdup, vcombine with generic vector code
llvm-svn: 105588
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
- change isShuffleMaskLegal to show that all shuffles with 32-bit and 64-bit
  elements are legal
- the Neon shuffle instructions do not support 64-bit elements, but we were
  not checking for that before lowering shuffles to use them
- remove some 64-bit element vduplane patterns that are no longer needed
llvm-svn: 105586
 | 
| | 
| 
| 
| 
| 
| 
|  | 
that it is an immediate before checking that the instruction is an
EXTRACT_SUBREG.
llvm-svn: 105585
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
- We actually pretend that we have two separate types for LLVM assembly/bitcode because we need to use the standard suffixes with LTO ('clang -O4 -c t.c' should generate 't.o').
It is now possible to do something like:
  $ clang -emit-llvm -S t.c -o t.ll ... assorted other compile flags ...
  $ clang -c t.ll -o t.o ... assorted other compile flags ...
and expect that the output will be almost* identical to:
  $ clang -c t.c -o t.o ... assorted other compile flags ...
because all the target settings (default CPU, target features, etc.) will all be initialized properly by the driver/frontend.
*: This isn't perfect yet, because in practice we will end up running the optimization passes twice. It's possible to get something equivalent out with a well placed -mllvm -disable-llvm-optzns, but I'm still thinking about the cleanest way to solve this problem more generally.
llvm-svn: 105584
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
- This magically enables using 'clang -cc1' as a replacement for most of 'llvm-as', 'llvm-dis', 'llc' and 'opt' functionality.
For example, 'llvm-as' is:
  $ clang -cc1 -emit-llvm-bc FOO.ll -o FOO.bc
and 'llvm-dis' is:
  $ clang -cc1 -emit-llvm    FOO.bc -o -
and 'opt' is, e.g.:
  $ clang -cc1 -emit-llvm -O3 -o FOO.opt.ll FOO.ll
and 'llc' is, e.g.:
  $ clang -cc1 -S -o - FOO.ll
The nice thing about using the backend tools this way is that they are guaranteed to exactly match how the compiler generates code (for example, setting the same backend options).
llvm-svn: 105583
 | 
| | 
| 
| 
| 
| 
|  | 
- These inputs follow an abbreviated execution path, but are still worth handling by FrontendAction so they reuse all the other clang -cc1 features.
llvm-svn: 105582
 | 
| | 
| 
| 
|  | 
llvm-svn: 105581
 | 
| | 
| 
| 
|  | 
llvm-svn: 105580
 | 
| | 
| 
| 
| 
| 
|  | 
to parallel what is done for AST inputs.
llvm-svn: 105579
 | 
| | 
| 
| 
| 
| 
|  | 
instead of an IsAST bool.
llvm-svn: 105578
 | 
| | 
| 
| 
|  | 
llvm-svn: 105577
 | 
| | 
| 
| 
| 
| 
|  | 
create modules which have target data strings.
llvm-svn: 105576
 | 
| | 
| 
| 
|  | 
llvm-svn: 105575
 | 
| | 
| 
| 
| 
| 
|  | 
argument to BackendConsumer.
llvm-svn: 105574
 | 
| | 
| 
| 
|  | 
llvm-svn: 105573
 | 
| | 
| 
| 
|  | 
llvm-svn: 105561
 | 
| | 
| 
| 
| 
| 
| 
|  | 
type of rhs need be compared to setter's argument and
not the getter type. Fixes radar 8062778
llvm-svn: 105560
 | 
| | 
| 
| 
|  | 
llvm-svn: 105559
 | 
| | 
| 
| 
| 
| 
|  | 
rdar://7797940
llvm-svn: 105557
 | 
| | 
| 
| 
|  | 
llvm-svn: 105556
 | 
| | 
| 
| 
|  | 
llvm-svn: 105554
 |