| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
| |
A function using any RC alias is enough to enable the ExeDepsFix pass.
llvm-svn: 144636
|
| |
|
|
| |
llvm-svn: 144635
|
| |
|
|
| |
llvm-svn: 144634
|
| |
|
|
| |
llvm-svn: 144633
|
| |
|
|
|
|
| |
of PseudoSourceValue from lib/Target/.
llvm-svn: 144632
|
| |
|
|
| |
llvm-svn: 144631
|
| |
|
|
|
|
| |
256-bit integer instructions when AVX2 isn't enabled.
llvm-svn: 144629
|
| |
|
|
|
|
| |
non-deterministic behavior.
llvm-svn: 144628
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
block sequence when recovering from unanalyzable control flow
constructs, *always* use the function sequence. I'm not sure why I ever
went down the path of trying to use the loop sequence, it is
fundamentally not the correct sequence to use. We're trying to preserve
the incoming layout in the cases of unreasonable control flow, and that
is only encoded at the function level. We already have a filter to
select *exactly* the sub-set of blocks within the function that we're
trying to form into a chain.
The resulting code layout is also significantly better because of this.
In several places we were ending up with completely unreasonable control
flow constructs due to the ordering chosen by the loop structure for its
internal storage. This change removes a completely wasteful vector of
basic blocks, saving memory allocation in the common case even though it
costs us CPU in the fairly rare case of unnatural loops. Finally, it
fixes the latest crasher reduced out of GCC's single source. Thanks
again to Benjamin Kramer for the reduction, my bugpoint skills failed at
it.
llvm-svn: 144627
|
| |
|
|
|
|
| |
enable converting between 256-bit PS/PD operations when AVX1 is enabled. Fixes PR11370.
llvm-svn: 144622
|
| |
|
|
|
|
| |
integer variants. rdar://10437054
llvm-svn: 144608
|
| |
|
|
|
|
| |
rdar://10435076
llvm-svn: 144606
|
| |
|
|
| |
llvm-svn: 144603
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Two new TargetInstrInfo hooks lets the target tell ExecutionDepsFix
about instructions with partial register updates causing false unwanted
dependencies.
The ExecutionDepsFix pass will break the false dependencies if the
updated register was written in the previoius N instructions.
The small loop added to sse-domains.ll runs twice as fast with
dependency-breaking instructions inserted.
llvm-svn: 144602
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Keep track of the last instruction to define each register individually
instead of per DomainValue. This lets us track more accurately when a
register was last written.
Also track register ages across basic blocks. When entering a new
basic block, use the least stale predecessor def as a worst case
estimate for register age.
The register age is used to arbitrate between conflicting domains. The
most recently defined register wins.
llvm-svn: 144601
|
| |
|
|
|
|
| |
link it against llvm code, by making our definitions weak. "Some users."
llvm-svn: 144596
|
| |
|
|
|
|
| |
rdar://10435076
llvm-svn: 144593
|
| |
|
|
|
|
| |
rdar://10435076
llvm-svn: 144592
|
| |
|
|
| |
llvm-svn: 144589
|
| |
|
|
|
|
|
| |
Make it easier to deal with aliases for instructions that do require a suffix
but accept more specific variants of the same size.
llvm-svn: 144588
|
| |
|
|
|
|
| |
rdar://10435076
llvm-svn: 144587
|
| |
|
|
|
|
|
| |
violating a dependency is to emit all loads prior to stores. This would likely
cause a great deal of spillage offsetting any potential gains.
llvm-svn: 144585
|
| |
|
|
|
|
|
| |
Canonicallize on the non-suffixed form, but continue to accept assembly that
has any correctly sized type suffix.
llvm-svn: 144583
|
| |
|
|
|
|
|
|
|
|
| |
and stores capture) to permit the caller to see each capture point and decide
whether to continue looking.
Use this inside memdep to do an analysis that basicaa won't do. This lets us
solve another devirtualization case, fixing PR8908!
llvm-svn: 144580
|
| |
|
|
|
|
| |
rdar://10412592
llvm-svn: 144578
|
| |
|
|
|
|
| |
into registers, rather then encoded directly in the load/store.
llvm-svn: 144576
|
| |
|
|
|
|
| |
rdar://10435076
llvm-svn: 144575
|
| |
|
|
| |
llvm-svn: 144569
|
| |
|
|
|
|
|
|
| |
"kill". This looks like a bug upstream. Since that's going to take some time
to understand, loosen the assertion and disable the optimization when
multiple kills are seen.
llvm-svn: 144568
|
| |
|
|
|
|
|
|
|
|
|
|
| |
These annotations are disabled entirely when either ENABLE_THREADS is off, or
building a release build. When enabled, they add calls to functions with no
statements to ManagedStatic's getters.
Use these annotations to inform tsan that the race used inside ManagedStatic
initialization is actually benign. Thanks to Kostya Serebryany for helping
write this patch!
llvm-svn: 144567
|
| |
|
|
| |
llvm-svn: 144566
|
| |
|
|
|
|
| |
rdar://10412592
llvm-svn: 144565
|
| |
|
|
| |
llvm-svn: 144560
|
| |
|
|
|
|
|
|
|
| |
instructions of the two-address operands) in order to avoid inserting copies.
This fixes the few regressions introduced when the two-address hack was
disabled (without regressing the improvements).
rdar://10422688
llvm-svn: 144559
|
| |
|
|
|
|
|
|
| |
Constant idx case is still done in tablegen but other cases are then expanded
Fixes <rdar://problem/10435460>
llvm-svn: 144557
|
| |
|
|
|
|
| |
simplify it.
llvm-svn: 144555
|
| |
|
|
| |
llvm-svn: 144554
|
| |
|
|
|
|
|
|
| |
N32/64 places all variable arguments in integer registers (or on stack),
regardless of their types, but follows calling convention of non-vaarg function
when it handles fixed arguments.
llvm-svn: 144553
|
| |
|
|
| |
llvm-svn: 144552
|
| |
|
|
|
|
| |
on custom implementations.
llvm-svn: 144551
|
| |
|
|
|
|
|
|
|
|
|
| |
argument registers on the callee's stack frame, along with functions that set
and get it.
It is not necessary to add the size of this area when computing stack size in
emitPrologue, since it has already been accounted for in
PEI::calculateFrameObjectOffsets.
llvm-svn: 144549
|
| |
|
|
|
|
|
|
| |
I broke this in r144515, it affected most ARM testers.
<rdar://problem/10441389>
llvm-svn: 144547
|
| |
|
|
|
|
|
| |
This still seems to be causing some failures. It needs more testing before
it gets enabled again.
llvm-svn: 144543
|
| |
|
|
| |
llvm-svn: 144538
|
| |
|
|
| |
llvm-svn: 144536
|
| |
|
|
|
|
|
|
| |
cleans up all the chains allocated during the processing of each
function so that for very large inputs we don't just grow memory usage
without bound.
llvm-svn: 144533
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
tests when I forcibly enabled block placement.
It is apparantly possible for an unanalyzable block to fallthrough to
a non-loop block. I don't actually beleive this is correct, I believe
that 'canFallThrough' is returning true needlessly for the code
construct, and I've left a bit of a FIXME on the verification code to
try to track down why this is coming up.
Anyways, removing the assert doesn't degrade the correctness of the algorithm.
llvm-svn: 144532
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
this pass. We're leaving already merged blocks on the worklist, and
scanning them again and again only to determine each time through that
indeed they aren't viable. We can instead remove them once we're going
to have to scan the worklist. This is the easy way to implement removing
them. If this remains on the profile (as I somewhat suspect it will), we
can get a lot more clever here, as the worklist's order is essentially
irrelevant. We can use swapping and fold the two loops to reduce
overhead even when there are many blocks on the worklist but only a few
of them are removed.
llvm-svn: 144531
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
time it is queried to compute the probability of a single successor.
This makes computing the probability of every successor of a block in
sequence... really really slow. ;] This switches to a linear walk of the
successors rather than a quadratic one. One of several quadratic
behaviors slowing this pass down.
I'm not really thrilled with moving the sum code into the public
interface of MBPI, but I don't (at the moment) have ideas for a better
interface. My direction I'm thinking in for a better interface is to
have MBPI actually retain much more state and make *all* of these
queries cheap. That's a lot of work, and would require invasive changes.
Until then, this seems like the least bad (ie, least quadratic)
solution. Suggestions welcome.
llvm-svn: 144530
|
| |
|
|
|
|
|
|
|
|
| |
correctly handle blocks whose successor weights sum to more than
UINT32_MAX. This is slightly less efficient, but the entire thing is
already linear on the number of successors. Calling it within any hot
routine is a mistake, and indeed no one is calling it. It also
simplifies the code.
llvm-svn: 144527
|