[PATCH] D17652: [CGP] Duplicate addressing computation in cold paths if required to sink addressing mode

Philip Reames via llvm-commits llvm-commits at lists.llvm.org
Wed Mar 2 16:22:54 PST 2016



On 03/02/2016 04:17 PM, Xinliang David Li wrote:
>
>
> On Wed, Mar 2, 2016 at 4:12 PM, Philip Reames 
> <listmail at philipreames.com <mailto:listmail at philipreames.com>> wrote:
>
>     reames added a comment.
>
>     In http://reviews.llvm.org/D17652#364797, @davidxl wrote:
>
>     > A general problem I see in address sinking optimization is the
>     lack of global cost analysis -- the analysis should consider
>     >
>     > 1. the cost of the folded instruction (if the address can be
>     folded in)
>     > 2. whether the original address instruction can be eliminated
>     (for instance, only sunk into some of the uses)
>     > 3. if the address can not be folded, what is the additional cost
>     > 4. what is the estimated register pressure reduction with the
>     address sinking
>
>
>     I'm confused by your comment.  Are you talking about my changes,
>     or the existing code?  The existing code does most of this (except
>     1) and my extension preserves all of that except when duplicating
>     into a cold call.
>
>
>
> Mostly the existing code, but you new code introduces a new dimension 
> to it. IIUC, the new code introduces the case where address 
> computation may not be folded away so there is also potential size 
> increase? Perhaps guard this change with 'not built for Os or Oz' ?
Sounds reasonable.
>
>
>     > The above should be all weighted with the block frequency
>     information.
>
>
>     While I agree, that's a separate change - particularly since CFG
>     does not currently use profiling info at all.
>
>
> Perhaps add a comment there to future cleanup ?
Sure.
>
> thanks,
>
> David
>
>
>
>     http://reviews.llvm.org/D17652
>
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160302/87296adb/attachment.html>


More information about the llvm-commits mailing list