| Age | Commit message (Collapse) | Author |
|
the sum of the edge weights not overflowing uint32, and crashed when
they did. This is generally safe as BranchProbabilityInfo tries to
provide this guarantee. However, the CFG can get modified during codegen
in a way that grows the *sum* of the edge weights. This doesn't seem
unreasonable (imagine just adding more blocks all with the default
weight of 16), but it is hard to come up with a case that actually
triggers 32-bit overflow. Fortuately, the single-source GCC build is
good at this. The solution isn't very pretty, but its no worse than the
previous code. We're already summing all of the edge weights on each
query, we can sum them, check for an overflow, compute a scale, and sum
them again.
I've included a *greatly* reduced test case out of the GCC source that
triggers it. It's a pretty lame test, as it clearly is just barely
triggering the overflow. I'd like to have something that is much more
definitive, but I don't understand the fundamental pattern that triggers
an explosion in the edge weight sums.
The buggy code is duplicated within this file. I'll colapse them into
a single implementation in a subsequent commit.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144526 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
offsets.
rdar://10412592
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144518 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
get loop info structures associated with them, and so we need some way
to make forward progress selecting and placing basic blocks. The
technique used here is pretty brutal -- it just scans the list of blocks
looking for the first unplaced candidate. It keeps placing blocks like
this until the CFG becomes tractable.
The cost is somewhat unfortunate, it requires allocating a vector of all
basic block pointers eagerly. I have some ideas about how to simplify
and optimize this, but I'm trying to get the logic correct first.
Thanks to Benjamin Kramer for the reduced test case out of GCC. Sadly
there are other bugs that GCC is tickling that I'm reducing and working
on now.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144516 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
second algorithm, but only loosely. It is more heavily based on the last
discussion I had with Andy. It continues to walk from the inner-most
loop outward, but there is a key difference. With this algorithm we
ensure that as we visit each loop, the entire loop is merged into
a single chain. At the end, the entire function is treated as a "loop",
and merged into a single chain. This chain forms the desired sequence of
blocks within the function. Switching to a single algorithm removes my
biggest problem with the previous approaches -- they had different
behavior depending on which system triggered the layout. Now there is
exactly one algorithm and one basis for the decision making.
The other key difference is how the chain is formed. This is based
heavily on the idea Andy mentioned of keeping a worklist of blocks that
are viable layout successors based on the CFG. Having this set allows us
to consistently select the best layout successor for each block. It is
expensive though.
The code here remains very rough. There is a lot that needs to be done
to clean up the code, and to make the runtime cost of this pass much
lower. Very much WIP, but this was a giant chunk of code and I'd rather
folks see it sooner than later. Everything remains behind a flag of
course.
I've added a couple of tests to exercise the issues that this iteration
was motivated by: loop structure preservation. I've also fixed one test
that was exhibiting the broken behavior of the previous version.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144495 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
mode. Fix predicate when in ARM mode and restore SelectIntrinsicCall.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144494 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
failures.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144492 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
SimplifyAddress to handle either a 12-bit unsigned offset or the ARM +/-imm8
offsets (addressing mode 3). This enables a load followed by an integer
extend to be folded into a single load.
For example:
ldrb r1, [r0] ldrb r1, [r0]
uxtb r2, r1 =>
mov r3, r2 mov r3, r1
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144488 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
It was off by default.
The new register allocators don't have the problems that made it
necessary to reallocate registers during stack slot coloring.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144481 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
The current register allocators all use the inline spiller.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144477 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Counting the number of occurences of each opcode is not a useful test.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144474 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Or maybe we are just getting lucky.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144473 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144472 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Filed PR11364 to track the problem. Should the register allocator
eliminate dead code?
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144471 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This test was committed with a bugfix to RemoveCopyByCommutingDef, but
that optimization is no longer triggered by this test.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144470 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This test is for a very specific LocalRewriter bug. LocalRewriter is
going away.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144469 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
I don't think this test does what is was supposed to do, and
LocalRewriter is going away anyway.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144463 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144462 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144461 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144460 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This test doesn't expose the issue with RAGreedy.
I filed PR11363 to track the missing InlineSpiller feature.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144459 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
The test is checking that the output doesn't contains any 'mov '
strings. It does contain movl, though.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144458 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
patterns instead of custom lowering code.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144457 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
runs. Fixes PR11029.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144438 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144426 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144425 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Fixes PR8113.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144409 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144388 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144380 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
rdar://10412592
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144376 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144361 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
rdar://10412592
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144348 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
For correctness, disable this for now.
rdar://10418009
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144316 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
bots to specify explicit -mtriple=x86_64-darwin.
I guess it expects -relocation-model=pic.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144290 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
instruction lower optimization" in the pre-RA scheduler.
The optimization, rather the hack, was done before MI use-list was available.
Now we should be able to implement it in a better way, perhaps in the
two-address pass until a MI scheduler is available.
Now that the scheduler has to backtrack to handle call sequences. Adding
artificial scheduling constraints is just not safe. Furthermore, the hack
is not taking all the other scheduling decisions into consideration so it's just
as likely to pessimize code. So I view disabling this optimization goodness
regardless of PR11314.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144267 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
determine if the value is negative and flip the sign accordingly.
rdar://10422026
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144258 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
The TII.foldMemoryOperand hook preserves implicit operands from the
original instruction. This is not what we want when those implicit
operands refer to the register being spilled.
Implicit operands referring to other registers are preserved.
This fixes PR11347.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144247 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144241 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
issue from PR11319.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144216 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144212 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144209 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
dragonegg self-host buildbot will recover (it is complaining about object
files differing between different build stages). Original commit message:
Add a hack to the scheduler to disable pseudo-two-address dependencies in
basic blocks containing calls. This works around a problem in which
these artificial dependencies can get tied up in calling seqeunce
scheduling in a way that makes the graph unschedulable with the current
approach of using artificial physical register dependencies for calling
sequences. This fixes PR11314.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144188 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144187 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Add AVX2 logical operations to list of replaceable instructions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144179 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144176 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144174 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
remove a fair number of unnecessary materialized constants.
rdar://10412592
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144163 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
During the initial RPO traversal of the basic blocks, remember the ones
that are incomplete because of back-edges from predecessors that haven't
been visited yet.
After the initial RPO, revisit all those loop headers so the incoming
DomainValues on the back-edges can be properly collapsed.
This will properly fix execution domains on software pipelined code,
like the included test case.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144151 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
basic blocks containing calls. This works around a problem in which
these artificial dependencies can get tied up in calling seqeunce
scheduling in a way that makes the graph unschedulable with the current
approach of using artificial physical register dependencies for calling
sequences. This fixes PR11314.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144124 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
ldm or ldr pairs.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144123 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144104 91177308-0d34-0410-b5e6-96231b3b80d8
|