Lawrence
2015-Jul-15 00:42 UTC
[LLVMdev] FW: Insight of 403050abcc091260be2e8f58484e7a39c0782b47?
+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 <mailto: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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150714/167da4d6/attachment.html>
Daniel Berlin
2015-Jul-15 01:54 UTC
[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 >