|  | Commit message (Collapse) | Author | Age | Files | Lines | 
|---|
| ... |  | 
| | 
| 
| 
| | llvm-svn: 147197 | 
| | 
| 
| 
| | llvm-svn: 147127 | 
| | 
| 
| 
| 
| 
| | Fixes <rdar://problem/10584116>
llvm-svn: 147125 | 
| | 
| 
| 
| 
| 
| | don't get any serious benefit there.
llvm-svn: 147101 | 
| | 
| 
| 
| 
| 
| | - Add some constantness.
llvm-svn: 147090 | 
| | 
| 
| 
| 
| 
| | include to LiveIntervalUnion.cpp file.
llvm-svn: 147089 | 
| | 
| 
| 
| | llvm-svn: 147088 | 
| | 
| 
| 
| | llvm-svn: 147071 | 
| | 
| 
| 
| | llvm-svn: 146987 | 
| | 
| 
| 
| | llvm-svn: 146986 | 
| | 
| 
| 
| 
| 
| | likely to stay either way that discussion ends up resolving itself.
llvm-svn: 146966 | 
| | 
| 
| 
| 
| 
| | http://llvm.org/docs/CodingStandards.html#ll_virtual_anch
llvm-svn: 146960 | 
| | 
| 
| 
| | llvm-svn: 146927 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | unpredicated. That is, turn
 subeq  r0, r1, #1
 addne  r0, r1, #1                                                                                                                                                                                                     
into
 sub    r0, r1, #1
 addne  r0, r1, #1
For targets where conditional instructions are always executed, this may be
beneficial. It may remove pseudo anti-dependency in out-of-order execution
CPUs. e.g.
 op    r1, ...
 str   r1, [r10]        ; end-of-life of r1 as div result
 cmp   r0, #65
 movne r1, #44  ; raw dependency on previous r1
 moveq r1, #12
If movne is unpredicated, then
 op    r1, ...
 str   r1, [r10]
 cmp   r0, #65
 mov   r1, #44  ; r1 written unconditionally
 moveq r1, #12
Both mov and moveq are no longer depdendent on the first instruction. This gives
the out-of-order execution engine more freedom to reorder them.
This has passed entire LLVM test suite. But it has not been enabled for any ARM
variant pending more performance evaluation.
rdar://8951196
llvm-svn: 146914 | 
| | 
| 
| 
| | llvm-svn: 146897 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | Now that getMatchingSuperRegClass() returns accurate results, it can be
used to compute constraints imposed by instructions using a sub-register
of a virtual register.
This means we can recompute the register class of any virtual register
by combining the constraints from all its uses.
llvm-svn: 146874 | 
| | 
| 
| 
| 
| 
| | attribute themselve.
llvm-svn: 146851 | 
| | 
| 
| 
| 
| 
| | asm parsing and testcase.
llvm-svn: 146801 | 
| | 
| 
| 
| | llvm-svn: 146784 | 
| | 
| 
| 
| | llvm-svn: 146783 | 
| | 
| 
| 
| | llvm-svn: 146780 | 
| | 
| 
| 
| | llvm-svn: 146702 | 
| | 
| 
| 
| 
| 
| | Patch by Kyriakos Georgiou!
llvm-svn: 146670 | 
| | 
| 
| 
| 
| 
| | but the existing code can't do it correctly. PR11570.
llvm-svn: 146630 | 
| | 
| 
| 
| 
| 
| | These are already marked as illegal by default.
llvm-svn: 146623 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| | into Analysis as a standalone function, since there's no need for
it to be in VMCore. Also, update it to use isKnownNonZero and
other goodies available in Analysis, making it more precise,
enabling more aggressive optimization.
llvm-svn: 146610 | 
| | 
| 
| 
| 
| 
| 
| 
| | On ARM, peephole optimization for ABS creates a trivial cfg triangle which tempts machine sink to sink instructions in code which is really straight line code. Sometimes this sinking may alter register allocator input such that use and def of a reg is divided by a branch in between, which may result in extra spills. Now mahine sink avoids sinking if final sink destination is post dominator.
Radar 10266272.
llvm-svn: 146604 | 
| | 
| 
| 
| 
| 
| 
| | with the correct iterator.
<rdar://problem/10530851>
llvm-svn: 146600 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | r0 = mov #0
r0 = moveq #1
Then the second instruction has an implicit data dependency on the first
instruction. Sadly I have yet to come up with a small test case that
demonstrate the post-ra scheduler taking advantage of this.
llvm-svn: 146583 | 
| | 
| 
| 
| | llvm-svn: 146550 | 
| | 
| 
| 
| | llvm-svn: 146548 | 
| | 
| 
| 
| | llvm-svn: 146547 | 
| | 
| 
| 
| | llvm-svn: 146546 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| | to finalize MI bundles (i.e. add BUNDLE instruction and computing register def
  and use lists of the BUNDLE instruction) and a pass to unpack bundles.
- Teach more of MachineBasic and MachineInstr methods to be bundle aware.
- Switch Thumb2 IT block to MI bundles and delete the hazard recognizer hack to
  prevent IT blocks from being broken apart.
llvm-svn: 146542 | 
| | 
| 
| 
| | llvm-svn: 146534 | 
| | 
| 
| 
| 
| 
| | instructions that define aggregate types.
llvm-svn: 146492 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| | Fast ISel isn't able to handle 'insertvalue' and it causes a large slowdown
during -O0 compilation. We don't necessarily need to generate an aggregate of
the values here if they're just going to be extracted directly afterwards.
<rdar://problem/10530851>
llvm-svn: 146481 | 
| | 
| 
| 
| 
| 
| | DW_FORM_flag. Use DW_FORM_data1 for one byte.
llvm-svn: 146475 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | undefined result. This adds new ISD nodes for the new semantics,
selecting them when the LLVM intrinsic indicates that the undef behavior
is desired. The new nodes expand trivially to the old nodes, so targets
don't actually need to do anything to support these new nodes besides
indicating that they should be expanded. I've done this for all the
operand types that I could figure out for all the targets. Owners of
various targets, please review and let me know if any of these are
incorrect.
Note that the expand behavior is *conservatively correct*, and exactly
matches LLVM's current behavior with these operations. Ideally this
patch will not change behavior in any way. For example the regtest suite
finds the exact same instruction sequences coming out of the code
generator. That's why there are no new tests here -- all of this is
being exercised by the existing test suite.
Thanks to Duncan Sands for reviewing the various bits of this patch and
helping me get the wrinkles ironed out with expanding for each target.
Also thanks to Chris for clarifying through all the discussions that
this is indeed the approach he was looking for. That said, there are
likely still rough spots. Further review much appreciated.
llvm-svn: 146466 | 
| | 
| 
| 
| | llvm-svn: 146453 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | subdirectories to traverse into.
 - Originally I wanted to avoid this and just autoscan, but this has one key
   flaw in that new subdirectories can not automatically trigger a rerun of the
   llvm-build tool. This is particularly a pain when switching back and forth
   between trees where one has added a subdirectory, as the dependencies will
   tend to be wrong. This will also eliminates FIXME implicitly.
llvm-svn: 146436 | 
| | 
| 
| 
| 
| 
| 
| 
| | If we create new intervals for a variable that is being spilled, then those new intervals are not guaranteed to also spill.  This means that anything reading from the original spilling value might not get the correct value if spills were missed.
Fixes <rdar://problem/10546864>
llvm-svn: 146428 | 
| | 
| 
| 
| | llvm-svn: 146409 | 
| | 
| 
| 
| 
| 
| | Disable while I investigate.
llvm-svn: 146331 | 
| | 
| 
| 
| | llvm-svn: 146327 | 
| | 
| 
| 
| 
| 
| | rdar://10530851
llvm-svn: 146276 | 
| | 
| 
| 
| 
| 
| | TargetInstrInfoImpl to break Target's dependency on CodeGen.
llvm-svn: 146247 | 
| | 
| 
| 
| | llvm-svn: 146226 | 
| | 
| 
| 
| | llvm-svn: 146220 | 
| | 
| 
| 
| | llvm-svn: 146219 |