[PATCH] D32252: [GVN] Add phi-translate for scalarpre as a temporary solution

[Wei Mi via llvm-commits]

On Fri, May 5, 2017 at 9:22 AM, Daniel Berlin <dberlin at dberlin.org> wrote:
>
>
> On Mon, May 1, 2017 at 6:56 PM, Wei Mi <wmi at google.com> wrote:
>>
>> > This also needs compile time and performance measurements.
>>
>> I used spec2006 to do compile time testing. The compile time had a
>> small increase.
>>
>> 400.perlbench       0.54%
>> 401.bzip2              1.62%
>> 403.gcc                 0.79%
>> 429.mcf                 1.15%
>> 433.milc                 0.24%
>> 445.gobmk             0.71%
>> 456.hmmer            0.26%
>> 458.sjeng              -0.53%
>> 462.libquantum     0.22%
>> 464.h264ref          -0.18%
>> 470.lbm                 0.86%
>> 482.sphinx3           -1.01%
>> 998.specrand        -2.35%
>> 999.specrand        -3.45%
>> 444.namd              0.46%
>> 447.dealII              1.65%
>> 450.soplex             0.92%
>> 453.povray             0.88%
>> 471.omnetpp          1.77%
>> 473.astar                1.23%
>> 483.xalancbmk       1.33%
>>
>> However, the compile time increase is not caused by phiTranslate call,
>> but caused by some data structure setting like numberingExpression map
>> (I removed the phiTranslate call and the compile time increase is
>> almost the same). I think that is because GVN is already a big compile
>> time consumer (top3 according to
>> http://lists.llvm.org/pipermail/llvm-dev/2016-November/107110.html),
>> and even small increase in the existing cost will be reflected in the
>> total compile time.
>>
>> Considering this is a temporary solution, is this compile time
>> increase acceptable?
>
>
> Are you willing to commit to solving it?
>
> I'm generally going to be okay with increasing compile time a bit if the
> same people are willing to commit to solving that, but less so if they just
> want someone else to solve it later :)
>

Considering the compile time issue is to be fixed, I tend to take
another try first before committing it, hopefully I can find a
solution or at least to understand better why such a small change
(adding a densemap) will contribute to the total compile time.

Thanks,
Wei.