| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
| |
llvm-svn: 113689
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
the end of the line on a parser error, allowing skipping to happen
for syntactic errors but not for semantic errors. Before we would
miss emitting a diagnostic about the second line, because we skipped
it due to the semantic error on the first line:
foo %eax
bar %al
This fixes rdar://8414033 - llvm-mc ignores lines after an invalid instruction mnemonic errors
llvm-svn: 113688
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
of the and's mask.
This can result in increased opportunities for store narrowing in code generation. Update a number of
tests for this change. This fixes <rdar://problem/8285027>.
Additionally, because this inverts the order of ors and ands, some patterns for optimizing or-of-and-of-or
no longer fire in instances where they did originally. Add a simple transform which recaptures most of these
opportunities: if we have an or-of-constant-or and have failed to fold away the inner or, commute the order
of the two ors, to give the non-constant or a chance for simplification instead.
llvm-svn: 113679
|
| |
|
|
| |
llvm-svn: 113670
|
| |
|
|
| |
llvm-svn: 113666
|
| |
|
|
|
|
|
| |
the 'zero' bit down into the back-end. There are other cases where this logic
isn't sufficient, so they should be handled separately.
llvm-svn: 113665
|
| |
|
|
| |
llvm-svn: 113662
|
| |
|
|
| |
llvm-svn: 113659
|
| |
|
|
| |
llvm-svn: 113654
|
| |
|
|
| |
llvm-svn: 113653
|
| |
|
|
|
|
| |
used for fast-isel.
llvm-svn: 113652
|
| |
|
|
|
|
| |
Reassociate does this but it doesn't catch all cases (e.g. if the operands are i1).
llvm-svn: 113651
|
| |
|
|
| |
llvm-svn: 113647
|
| |
|
|
|
|
|
| |
iterator when an optimization took place. This allows us to do more insane
things with the code than just remove an instruction or two.
llvm-svn: 113640
|
| |
|
|
|
|
| |
rdar://8302157
llvm-svn: 113637
|
| |
|
|
| |
llvm-svn: 113632
|
| |
|
|
|
|
|
| |
(The Ada bindings probably need it too, but all the
obvious places to change say "do not edit this file".)
llvm-svn: 113618
|
| |
|
|
|
|
| |
string.
llvm-svn: 113615
|
| |
|
|
| |
llvm-svn: 113614
|
| |
|
|
| |
llvm-svn: 113610
|
| |
|
|
| |
llvm-svn: 113608
|
| |
|
|
|
|
| |
understand (the log file was no help).
llvm-svn: 113605
|
| |
|
|
| |
llvm-svn: 113603
|
| |
|
|
|
|
| |
"llvm.eh.catch.all.value". Only the name needs to be changed.
llvm-svn: 113600
|
| |
|
|
|
|
| |
fixed operands from the total number of operands (including the variadic ones).
llvm-svn: 113597
|
| |
|
|
|
|
|
|
| |
a sweet spot in the performance per
code size increase curve.
llvm-svn: 113595
|
| |
|
|
|
|
|
| |
that the memoperands are properly set after DAG building and general mucking
about.
llvm-svn: 113585
|
| |
|
|
| |
llvm-svn: 113584
|
| |
|
|
|
|
|
|
|
|
| |
to use AddrMode4, there was a count of the registers stored in one of the
operands. I changed that to just count the operands but forgot to adjust for
the size of D registers. This was noticed by Evan as a performance problem
but it is a potential correctness bug as well, since it is possible that this
could merge a base update with a non-matching immediate.
llvm-svn: 113576
|
| |
|
|
|
|
|
|
|
|
|
| |
take multiple cycles to decode.
For the current if-converter clients (actually only ARM), the instructions that
are predicated on false are not nops. They would still take machine cycles to
decode. Micro-coded instructions such as LDM / STM can potentially take multiple
cycles to decode. If-converter should take treat them as non-micro-coded
simple instructions.
llvm-svn: 113570
|
| |
|
|
| |
llvm-svn: 113566
|
| |
|
|
|
|
| |
more clear. No functional change.
llvm-svn: 113565
|
| |
|
|
|
|
| |
bad as I'd thought.
llvm-svn: 113561
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
is different from what the code now uses in a two ways: NamedMDNodes
were considered Values and included in the numbering, and the
function-local metadata counter wasn't reset between functions.
The later problem breaks lazy deserialization, so instead of trying
to emulate the old numbering, just drop the old metadata. The only
in-tree use case is debug info with LTO, where the QOI loss is
considered acceptable.
llvm-svn: 113557
|
| |
|
|
|
|
|
|
| |
section.
- This is annoying, because we have to scatter this check everywhere that could emit real data, but I see no better solution.
llvm-svn: 113552
|
| |
|
|
| |
llvm-svn: 113551
|
| |
|
|
|
|
| |
some data around and implement a couple of move routines to do this.
llvm-svn: 113546
|
| |
|
|
| |
llvm-svn: 113539
|
| |
|
|
|
|
| |
regular value references.
llvm-svn: 113538
|
| |
|
|
| |
llvm-svn: 113537
|
| |
|
|
|
|
| |
Truncate when truncating, extend when extending.
llvm-svn: 113536
|
| |
|
|
|
|
|
|
|
|
|
| |
with calls, is
not unrolling loops that contain calls that would be better off getting inlined. This mostly
comes up when an interleaved devirtualization pass has devirtualized a call which the inliner
will inline on a future pass. Thus, rather than blocking all loops containing calls, add
a metric for "inline candidate calls" and block loops containing those instead.
llvm-svn: 113535
|
| |
|
|
| |
llvm-svn: 113533
|
| |
|
|
|
|
|
|
| |
cannot be unrolled. After some discussion,
there seems to be a better way to achieve the same effect.
llvm-svn: 113528
|
| |
|
|
|
|
| |
Revert it.
llvm-svn: 113527
|
| |
|
|
| |
llvm-svn: 113526
|
| |
|
|
|
|
|
|
| |
when we unroll a loop.
Next step is to recalculate the threshold values given this new heuristic.
llvm-svn: 113525
|
| |
|
|
| |
llvm-svn: 113523
|
| |
|
|
| |
llvm-svn: 113522
|
| |
|
|
| |
llvm-svn: 113521
|