[LLVMdev] FW: Insight of 403050abcc091260be2e8f58484e7a39c0782b47?

Daniel Berlin dberlin at dberlin.org
Tue Jul 14 18:54:20 PDT 2015


Simple register pressure heuristics for PRE rarely work.

If we wanted to do something better for PRE, the real answer is
something like min-cut PRE.

On Tue, Jul 14, 2015 at 5:42 PM, Lawrence <lawrence at codeaurora.org> wrote:
> +llvmdev
>
>
>
> From: Lawrence [mailto:lawrence at codeaurora.org]
> Sent: Tuesday, July 14, 2015 5:42 PM
> To: 'dberlin at dberlin.org'
> Cc: 'Ana Pazos'; 'Sanjin Sijaric'; 'zinob at codeaurora.org'
> Subject: RE: Insight of 403050abcc091260be2e8f58484e7a39c0782b47?
>
>
>
> Thanks Daniel for your prompt response.
>
>
>
> I understand the problem is a combination of multiple things, I have opened
> at least one RA bug for it.
>
>
>
> One thing I am not sure is should we add some register pressure mechanism to
> your patch (or even PRE) or fix later optimization such as
> rematerialization/split/spiller/coalescing(?) to handle that.
>
>
>
> +llvmdev for more discussion
>
>
>
> Will attached two log more detail to individual if anyone ask.
>
>
>
> Regards.
>
>
>
> Lawrence Hu
>
>
>
>
>
> From: Lawrence [mailto:lawrence at codeaurora.org]
> Sent: Tuesday, July 14, 2015 3:16 PM
> To: 'dberlin at dberlin.org'
> Cc: 'Ana Pazos'; 'Sanjin Sijaric'; 'zinob at codeaurora.org'
> Subject: Insight of 403050abcc091260be2e8f58484e7a39c0782b47?
>
>
>
> Hi, Daniel:
>
>
>
> I am investigating the performance of a version of open source
> bzip2/decompress, I found out that your patch
>
>
>
> commit 403050abcc091260be2e8f58484e7a39c0782b47
>
> Author: Daniel Berlin <dberlin at dberlin.org>
>
> Date:   Tue Feb 3 20:37:08 2015 +0000
>
>
>
>     Allow PRE to insert no-cost phi nodes
>
>
>
> changed some getelementptr to PHIs, which introduced a lot more long live
> ranges, that leaded to almost 3 times more Spill/Reloads from register
> allocation, as a result, it degraded the performance of bzip2/decompress by
> 16%.
>
>
>
> Attached are two log files, log.good without your change, log.bad with your
> change.
>
>
>
>
>
> I couldn’t understand your patch well just base on the description and
> comments, could you please give me some insight about the intention of the
> patch and possible way of limiting it to avoid that performance degradation?
>
>
>
> Your help is highly appreciated.
>
>
>
> Regards
>
>
>
> Lawrence Hu.
>
>
>
>
>
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>




More information about the llvm-dev mailing list