[llvm-dev] A code layout related side-effect introduced by rL318299

[Wei Mi via llvm-dev]

For the hot conditional branch, I guess you mean "jbe .LBB0_3" in BB#2. If
"jbe .LBB0_3" fall through into loop header .LBB0_3, then it is impossible
for "ja .LBB0_5" in BB#0 to fall through into .LBB0_3. We cannot achieve
both unless .LBB0_3 is duplicated (That is the possible solution listed at
the end of the original post, but for that solution we will have the code
size increase cost).


On Mon, Dec 18, 2017 at 5:01 PM, Chandler Carruth <chandlerc at google.com>
wrote:

> What I can't figure out is why we don't get the same basic block layout
> for b.ll....
>
> Specifically, I understand that we essentially have an iteration peeled
> out of the loop by loop rotation. But the result still should get the fancy
> layout that causes the hot conditional branch (away from the unreachable)
> to fall through into the loop header...
>
> On Mon, Dec 18, 2017 at 4:21 PM Wei Mi <wmi at google.com> wrote:
>
>> On Mon, Dec 18, 2017 at 4:14 PM, Wei Mi <wmi at google.com> wrote:
>>
>>> Hi,
>>>
>>> Recently 10% performance regression on an important benchmark showed up
>>> after we integrated https://reviews.llvm.org/rL318299. The analysis
>>> showed that rL318299 triggered loop rotation on an multi exits loop, and
>>> the loop rotation introduced code layout issue. The performance regression
>>> is a side-effect of rL318299. I got two testcases a.ll and b.ll attached to
>>> illustrate the problem. a.ll was generated by rL318298 and b.ll was
>>> generated by rL318299.
>>>
>>
>> a.ll and b.ll are generated from the same function by different versions
>> of compiler. a.s and b.s generated from a.ll and b.ll respectively showed
>> where the performance difference comes from.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171218/c117bb50/attachment.html>