[LLVMdev] Register pressure mechanism in PRE or Smarter rematerialization/split/spiller/coalescing ?

[Lawrence]

I thought about a little bit more, I think adding Register pressure control in your patch or PRE may be the only choice.

Because at least for this case I am looking at,  what your patch did is created more relatively complex long live range, rematerialization is not smart enough to undo your change or at least without a lot of work, coalescing only create even longer live range not shorter, Spiller can't help since it's the Spiller created Spill/Reloads due to high register pressure, Splitting can shorten the live ranges, but I don't think it can handle your case without a lot of work.

Suggestions are welcome.

-----Original Message-----
From: Daniel Berlin [mailto:dberlin at dberlin.org] 
Sent: Tuesday, July 14, 2015 6:54 PM
To: Lawrence
Cc: LLVM Developers Mailing List
Subject: Re: [LLVMdev] FW: Insight of 403050abcc091260be2e8f58484e7a39c0782b47?

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
>