| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
cases, it's much nicer and more informative reading the alias.
llvm-svn: 129497
|
| |
|
|
|
|
| |
the alias".
llvm-svn: 129485
|
| |
|
|
|
|
| |
where the RHS is of the legal type for the new operation.
llvm-svn: 129484
|
| |
|
|
|
|
| |
rdar://problem/9280370
llvm-svn: 129480
|
| |
|
|
|
|
|
|
| |
the same allocation size but different primitive sizes(e.g., <3xi32> and
<4xi32>). When ScalarRepl promotes them, it can't use a bit cast but
should use a shuffle vector instead.
llvm-svn: 129472
|
| |
|
|
|
|
|
|
| |
instructions (tBcc and t2Bcc).
rdar://problem/9280470
llvm-svn: 129471
|
| |
|
|
|
|
| |
rdar://problem/9279440
llvm-svn: 129469
|
| |
|
|
| |
llvm-svn: 129468
|
| |
|
|
| |
llvm-svn: 129467
|
| |
|
|
|
|
|
| |
ignored. There was a test to catch this, but it was just blindly updated in
a large change. This fixes another part of <rdar://problem/9275290>.
llvm-svn: 129466
|
| |
|
|
| |
llvm-svn: 129463
|
| |
|
|
|
|
|
|
| |
as such.
rdar://problem/9276651
llvm-svn: 129462
|
| |
|
|
|
|
| |
understand actual reason behind this fixme. Spot checking suggest that newer gdb does not need this.
llvm-svn: 129461
|
| |
|
|
|
|
| |
llvm-gcc-native-mingw32 builder.
llvm-svn: 129457
|
| |
|
|
|
|
|
|
| |
not properly handled.
rdar://problem/9276427
llvm-svn: 129456
|
| |
|
|
|
|
| |
http://llvm.org/viewvc/llvm-project?view=rev&revision=129387.
llvm-svn: 129451
|
| |
|
|
| |
llvm-svn: 129450
|
| |
|
|
|
|
|
|
|
| |
LoopUnroll class's ctor. Doing so
will allow multiple context with different loop unroll parameters to run. This is a minor change and no effect
on existing application.
llvm-svn: 129449
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Relocations between the object modules are properly resolved, as in the
following trivial example:
$ cat t.c
int foo();
int main() {
return foo();
}
$ cat foo.c
int foo() {
return 65;
}
$ clang -c t.c -fno-asynchronous-unwind-tables
$ clang -c foo.c -fno-asynchronous-unwind-tables
$ llvm-rtdyld t.o foo.o ; echo $?
loaded '_main' at: 0x10015c000
65
llvm-svn: 129448
|
| |
|
|
| |
llvm-svn: 129447
|
| |
|
|
| |
llvm-svn: 129446
|
| |
|
|
| |
llvm-svn: 129445
|
| |
|
|
|
|
|
|
|
| |
component names such as "engine" do not expand to "jit" and hence to
the native target libraries for external users.
Thanks to arrowdodger for reporting and diagnosing the problem.
llvm-svn: 129444
|
| |
|
|
|
|
| |
related tweaks to ExprMapKeyType.
llvm-svn: 129443
|
| |
|
|
| |
llvm-svn: 129442
|
| |
|
|
| |
llvm-svn: 129441
|
| |
|
|
| |
llvm-svn: 129440
|
| |
|
|
| |
llvm-svn: 129439
|
| |
|
|
| |
llvm-svn: 129437
|
| |
|
|
| |
llvm-svn: 129436
|
| |
|
|
| |
llvm-svn: 129435
|
| |
|
|
|
|
|
| |
the max itself, so it is not easy to write a test case for this, but I added a
test case that would fail if the code in AsmPrinter were removed.
llvm-svn: 129432
|
| |
|
|
| |
llvm-svn: 129429
|
| |
|
|
|
|
|
| |
alignment for its type, use the minimum of the specified alignment and the ABI
alignment. This fixes <rdar://problem/9275290>.
llvm-svn: 129428
|
| |
|
|
| |
llvm-svn: 129423
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
latency.
Additional fixes:
Do something reasonable for subtargets with generic
itineraries by handle node latency the same as for an empty
itinerary. Now nodes default to unit latency unless an itinerary
explicitly specifies a zero cycle stage or it is a TokenFactor chain.
Original fixes:
UnitsSharePred was a source of randomness in the scheduler: node
priority depended on the queue data structure. I rewrote the recent
VRegCycle heuristics to completely replace the old heuristic without
any randomness. To make the ndoe latency adjustments work, I also
needed to do something a little more reasonable with TokenFactor. I
gave it zero latency to its consumers and always schedule it as low as
possible.
llvm-svn: 129421
|
| |
|
|
| |
llvm-svn: 129419
|
| |
|
|
| |
llvm-svn: 129417
|
| |
|
|
|
|
| |
Implement the ones that were missing in the asm streamer.
llvm-svn: 129413
|
| |
|
|
|
|
| |
rdar://problem/9273947
llvm-svn: 129411
|
| |
|
|
|
|
|
|
|
|
| |
instructions.
The ARMARM specifies these instructions as unpredictable when storing the
writeback register. This shouldn't affect code generation much since storing a
pointer to itself is quite rare.
llvm-svn: 129409
|
| |
|
|
|
|
|
|
| |
registers for fast allocation.
Fixes rdar://9207598
llvm-svn: 129408
|
| |
|
|
| |
llvm-svn: 129407
|
| |
|
|
| |
llvm-svn: 129406
|
| |
|
|
| |
llvm-svn: 129405
|
| |
|
|
|
|
|
| |
values are also transmitted through branches which cause side effects to
be skipped altogether.
llvm-svn: 129404
|
| |
|
|
| |
llvm-svn: 129403
|
| |
|
|
|
|
| |
In case of multiple compile unit in one object file, each compile unit is responsible for its own set of type entries anyway. This refactoring makes this obvious.
llvm-svn: 129402
|
| |
|
|
|
|
|
|
|
| |
Now that we have a first-class way to represent unaligned loads, the unaligned
load intrinsics are superfluous.
First part of <rdar://problem/8460511>.
llvm-svn: 129401
|
| |
|
|
| |
llvm-svn: 129400
|