1
0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-10-23 13:02:52 +02:00
llvm-mirror/test/CodeGen
Chandler Carruth 0fe0191603 [MBP] Fix a really horrible bug in MachineBlockPlacement, but behind
a flag for now.

First off, thanks to Daniel Jasper for really pointing out the issue
here. It's been here forever (at least, I think it was there when
I first wrote this code) without getting really noticed or fixed.

The key problem is what happens when two reasonably common patterns
happen at the same time: we outline multiple cold regions of code, and
those regions in turn have diamonds or other CFGs for which we can't
just topologically lay them out. Consider some C code that looks like:

  if (a1()) { if (b1()) c1(); else d1(); f1(); }
  if (a2()) { if (b2()) c2(); else d2(); f2(); }
  done();

Now consider the case where a1() and a2() are unlikely to be true. In
that case, we might lay out the first part of the function like:

  a1, a2, done;

And then we will be out of successors in which to build the chain. We go
to find the best block to continue the chain with, which is perfectly
reasonable here, and find "b1" let's say. Laying out successors gets us
to:

  a1, a2, done; b1, c1;

At this point, we will refuse to lay out the successor to c1 (f1)
because there are still un-placed predecessors of f1 and we want to try
to preserve the CFG structure. So we go get the next best block, d1.

... wait for it ...

Except that the next best block *isn't* d1. It is b2! d1 is waaay down
inside these conditionals. It is much less important than b2. Except
that this is exactly what we didn't want. If we keep going we get the
entire set of the rest of the CFG *interleaved*!!!

  a1, a2, done; b1, c1; b2, c2; d1, f1; d2, f2;

So we clearly need a better strategy here. =] My current favorite
strategy is to actually try to place the block whose predecessor is
closest. This very simply ensures that we unwind these kinds of CFGs the
way that is natural and fitting, and should minimize the number of cache
lines instructions are spread across.

It also happens to be *dead simple*. It's like the datastructure was
specifically set up for this use case or something. We only push blocks
onto the work list when the last predecessor for them is placed into the
chain. So the back of the worklist *is* the nearest next block.

Unfortunately, a change like this is going to cause *soooo* many
benchmarks to swing wildly. So for now I'm adding this under a flag so
that we and others can validate that this is fixing the problems
described, that it seems possible to enable, and hopefully that it fixes
more of our problems long term.

llvm-svn: 231238
2015-03-04 12:18:08 +00:00
..
AArch64 Fix PR22408 - LLVM producing AArch64 TLS relocations that GNU linkers cannot handle yet. 2015-03-04 09:12:08 +00:00
ARM DebugInfo: Move new hierarchy into place 2015-03-03 17:24:31 +00:00
BPF
CPP
Generic DebugInfo: Move new hierarchy into place 2015-03-03 17:24:31 +00:00
Hexagon DebugInfo: Move new hierarchy into place 2015-03-03 17:24:31 +00:00
Inputs DebugInfo: Move new hierarchy into place 2015-03-03 17:24:31 +00:00
Mips Drop the "eh_" from eh_func_begin and eh_func_end. 2015-03-04 00:27:43 +00:00
MSP430
NVPTX
PowerPC Use the vanilla func_end symbol for .size. 2015-03-04 01:35:23 +00:00
R600
SPARC Use the vanilla func_end symbol for .size. 2015-03-04 01:35:23 +00:00
SystemZ
Thumb DebugInfo: Move new hierarchy into place 2015-03-03 17:24:31 +00:00
Thumb2
WinEH WinEH: Remove vestigial EH object 2015-03-03 23:20:30 +00:00
X86 [MBP] Fix a really horrible bug in MachineBlockPlacement, but behind 2015-03-04 12:18:08 +00:00
XCore DebugInfo: Move new hierarchy into place 2015-03-03 17:24:31 +00:00