[llvm-dev] [RFC] Add IR level interprocedural outliner for code size.

[River Riddle via llvm-dev]

Andrey,
  Currently it will not catch this case because congruence is determined by
types/opcode/etc, but cases like this can be caught by redefining what it
means to be congruent. We can redefine congruency for add/sub/icmp/gep/etc
to no longer care about types, or even opcodes, in certain cases. but this
may cause the need for extra control flow.

As for your example, the machine outliner can handle the case when the
addition amount and register are the same:
int x = (int) x2 + 4;
int *p = (int*)p2 + 1;

If we do relax the congruency restrictions, being at the IR level allows
for us to identify that we could outline more than just the simple case:
assuming: sizeof(int) == sizeof(int *) == sizeof(long long *) ==
sizeof(char *)

int x = (int)x2 + 1;
int *p = (int *)p2 + (int)ipidx;
long long*lp = (long long*)lp2 + 3;
char *cp = (char *)cp2 + (int)cpidx;

-- could outline to --
int x = outlinedFn(1, x2, 1);
int *p = (int *)outlinedFn(4, (int)p2, ipidx);
long long*lp = (long long*)outlinedFn(8, (int)lp2, 3);
char *cp = (char *)outlinedFn(1, (int)cp2, cpidx);

int outlinedFn(int SizePatchup, int Var, int Amount) {
  return Var + (SizePatchup * Amount);
}

In the above we need some extra patch-up to account for the different sizes
of the pointee types.

This is just one opportunity that can be caught when we start to redefine
equivalence, something that is really powerful at the IR level. We wanted
the initial submission to be have a compact and efficient implementation.
Extensions like these can easily be added, but it is not a part of the
initial design.
Thanks,
 River Riddle


On Sun, Jul 23, 2017 at 11:32 AM, <andreybokhanko at gmail.com> wrote:

> River,
>
> ...and one more thing that just occurred to me.
>
> Will Outlining put the following two expressions:
>
> int x = (int)x2 + 1
> int* p = (int *)p2 + 1
>
> into the same class of congruency? -- if sizeof(int) == sizeof(int *) on
> the target hardware?
>
> Even more interesting and relevant are pointers of different types.
>
> I believe MO has no problems capturing both of these.
>
> Yours,
> Andrey
>
> Отправлено с iPad
>
> 23 июля 2017 г., в 1:05, River Riddle <riddleriver at gmail.com> написал(а):
>
> Hi Andrey,
>  Questions and feedback are very much welcome.
> - The explanation as to why the improvements can vary between the IR and
> MIR outliner mainly boil down to the level of abstraction that each are
> working at. The MIR level has very accurate heuristics and is effectively
> the last post ISel target independent code gen pass. The IR outliner on the
> other hand has more estimation in the cost model, and can affect the
> decisions of function simplification passes, instruction selection, RA,
> etc. Taking this into account can lead to different results. Its important
> to remember the differences that being at a higher abstraction level can
> cause.
> - As for the spec(it is 2006, sorry I missed that) command line options,
> as well as any other benchmark, I only added "-Oz -mno-red-zone(to keep
> comparisons fair) -(whatever enables each transform)" to the default flags
> needed for compilation. I'll try to get the exact command line options used
> and add them.
> - Debug information(line numbers) is currently only kept if it is the same
> across all occurrences. This was simply a design choice and can be changed
> if keeping one instance is the desired behavior.
> - The behavior described with the profile data is already implemented, I
> will update the numbers to include the results after including pgo data.
> - The LTO results are very experimental given that there isn't a size
> pipeline for LTO yet(there should be). The %improvements can be similar to
> non LTO but because the LTO binary is generally much smaller the actual
> decrease in size is also much smaller. I'll add more detailed LTO numbers
> as well.
> Thanks,
> River Riddle
>
> On Sat, Jul 22, 2017 at 3:23 PM, Andrey Bokhanko <andreybokhanko at gmail.com
> > wrote:
>
>> Hi River,
>>
>> Very impressive! -- thanks for working on this.
>>
>> A few questions, if you don't mind.
>>
>> First, on results (from goo.gl/5k6wsP). Some of them are quite
>> surprising. In theory, "top improvements" should be quite similar in all
>> three approaches ("Early&Late Outlining", "Late Outlining" and "Machine
>> Outliner"), with E&LO capturing most of the cases. Yet, they are very
>> different:
>>
>> Test Suite, top improvements:
>> E&LO:
>>
>>    -
>>
>>    enc-3des: 66.31%
>>    -
>>
>>    StatementReordering-dbl: 51.45%
>>    -
>>
>>    Symbolics-dbl: 51.42%
>>    -
>>
>>    Recurrences-dbl: 51.38%
>>    -
>>
>>    Packing-dbl: 51.33%
>>
>> LO:
>>
>>    -
>>
>>    enc-3des: 50.7%
>>    -
>>
>>    ecbdes: 46.27%
>>    -
>>
>>    security-rjindael:45.13%
>>    -
>>
>>    ControlFlow-flt: 25.79%
>>    -
>>
>>    ControlFlow-dbl: 25.74%
>>
>> MO:
>>
>>    -
>>
>>    ecbdes: 28.22%
>>    -
>>
>>    Expansion-flt: 22.56%
>>    -
>>
>>    Recurrences-flt: 22.19%
>>    -
>>
>>    StatementReordering-flt: 22.15%
>>    -
>>
>>    Searching-flt: 21.96%
>>
>>
>> SPEC, top improvements:
>> E&LO:
>>
>>    -
>>
>>    bzip2: 9.15%
>>    -
>>
>>    gcc: 4.03%
>>    -
>>
>>    sphinx3: 3.8%
>>    -
>>
>>    H264ref: 3.24%
>>    -
>>
>>    Perlbench: 3%
>>
>> LO:
>>
>>    -
>>
>>    bzip2: 7.27%
>>    -
>>
>>    sphinx3: 3.65%
>>    -
>>
>>    Namd: 3.08%
>>    -
>>
>>    Gcc: 3.06%
>>    -
>>
>>    H264ref: 3.05%
>>
>> MO:
>>
>>    -
>>
>>    Namd: 7.8%
>>    -
>>
>>    bzip2: 7.27%
>>    -
>>
>>    libquantum: 2.99%
>>    -
>>
>>    h264ref: 2%
>>
>>
>> Do you understand why so?
>>
>> I'm especially interested in cases where MO managed to find redundancies
>> while E&O+LO didn't. For example, 2.99% on libquantum (or is it simply
>> below "top 5 results" for E&O+LO?) -- did you investigated this?
>>
>> Also, it would be nice to specify full options list for SPEC (I assume
>> SPEC CPU2006?), similar to how results are reported on spec.org.
>>
>> And a few questions on the RFC:
>>
>> On Fri, Jul 21, 2017 at 12:47 AM, River Riddle via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>
>>> * Debug Info:
>>>
>> Debug information is preserved for the calls to functions which have been
>>> outlined but all debug info from the original outlined portions is removed,
>>> making them harder to debug.
>>>
>>
>> Just to check I understand it correctly: you remove *all* debug info in
>> outlined functions, essentially making them undebuggable -- correct? Did
>> you considered copying debug info from one of outlined fragments instead?
>> -- at least line numbers?
>>
>> The execution time results are to be expected given that the outliner,
>>> without profile data, will extract from whatever region it deems
>>> profitable. Extracting from the hot path can lead to a noticeable
>>> performance regression on any platform, which can be somewhat avoided by
>>> providing profile data during outlining.
>>>
>>
>> Some of regressions are quite severe. It would be interesting to
>> implement what you stated above and measure -- both code size reductions
>> and performance degradations -- again.
>>
>>
>>> * LTO:
>>>
>>>    - LTO doesn’t have a code size pipeline, but %reductions over LTO are
>>> comparable to non LTO.
>>>
>>
>> LTO is known to affect code size significantly (for example, by removing
>> redundant functions), so I'm frankly quite surprised that the results are
>> the same...
>>
>> Yours,
>> Andrey
>> ===
>> Compiler Architect
>> NXP
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170723/74046cb6/attachment.html>