Hi Fred,
Thanks for your comments.
The reanming happens only when there are some dead phi/chi nodes revive in
CODEMAP::Iload_folded.
To evaluate how this patch will affect compile-time, I add dump when this
renaming happens.
Tested with SPEC2006 base/peak
Following cases have CODEMAP rename after create CODEMAPE, and renaming
count is seldom consider test's PU count..
447.dealII base/peak rename 20+ times
483.xalancbmk base/peak rename 30+ times
416.gamess peak rename 4 times
458.sjeng base rename 1 time.
So this renaming rarely happens and I think we can afford the increased
compile time.
And from another perspective. Rename_CODEMAP is already used in other phase
like aft CGF optimization, COMP_UNIT::Fold_lda_iload_istore, etc.
These optimizations and renaming are more likely happen.
One utiIity I hope WOPT can have is CODEMAP rename only rename somve AUX
(give in a table or list). Then rename cost can be decreased a lot.
For copy propagation issue.
The copy propagation happens in Dead_Store_Elminination,
DSE::Propagate_vsym_bb.
To disable the propagation, need change Dead_Store_Elimination. If one chi
node is live,
all other chi nodes binding to same statment and set_required should live
because they are aliased with each other.
This will also cause compile time isuee, because more live phi/chi node in
codrep.
Another issue is though we fix the copy propgation problem, the revive
logical is still there in CODEMAP::Iload_folded.
There still possible dead phi/chi nodes revive in CODEMAP creation. So
complete fix is rename after create CODEMAP.
The main issue is create_codemap not simply create coderep, it also perform
iload folding may change version.
If iload folding function is totolay peformed in
COMP_UNIT::Fold_lda_iload_istore, it has no problem.
Regards
Shi Hui
On Mon, Jul 4, 2011 at 9:26 PM, Fred Chow <frdc...@gmail.com> wrote:
> **
> Doing renaming is quite compile-time expensive, because it is like running
> the SSA construction algorithm. The problem your mentioned would not have
> occurred if sym2v3 has not been propagated down to STMT3. I don't recall we
> were doing copy propagation for chi operands. The overlapped live range was
> caused by this bad copy propagation, NOT by the ILOAD folding.
>
> The above copy propagation is bad because sym2v4 is NOT dead, because it
> aliases with the default vsym which appears in the mu of STMT2. So your fix
> should be in preventing the copy propagation.
>
> Fred
>
>
> On 06/29/2011 11:35 PM, Hui Shi wrote:
>
> Could gatekeeper help review this fix?
>
> In SSA::Create_CODEMAP ILOAD folding is performed during coderep setup.
> The problem is iload folding may revive some dead phi/chi node.
>
> For example
> STMT1
> sym2v4 = chi(sym2v3) NOT LIVE
> default_vsym_v4 = chi(default_vsym_v3) LIVE
> ....
> STMT2
> ILOAD mu(default_vsym_v4)
> ...
> STMT3
> sym2v5 = chi(sym2v3) LIVE // sym2v3 is propagate down from above dead chi.
> default_vsym_v5 = chi(default_vsym_v4)
>
> If sym2v4 may use at STMT2, ILOAD's MU node must on STMT1's chi list
> (because MU node must alias with sym2, otherwise its alias issue).
> And MU node's corresponding CHI node must live on STMT1, because
> set_required_mu will set chi node live.
> So it's okay for DSE to mark fisrt CHI dead if STMT1 and STMT3 write same
> memory location.
> 1. It will not make STMT1 dead, because the other chi node is live.
> 2. ILOAD's MU node's def statment still STMT1
>
> If ILOAD folding transform ILOAD to LDID and LDID's AUX is sym2.
> ILOD_FOLDING revives dead chi sym2v4 = chi(sym2v3) without update the late
> chi node's opnd.
>
> This introduce overlapped between sym2v3 and sym2v4.
> Fix is rename CODEMAP if iload folding revive dead phi/chi node.
> OPT_REVISE_SSA::Fold_lda_indirects also rename CODEMAP after optimization.
>
> Fix is
> 1. record in htable, if dead chi/phi node is revived in
> SSA::Create_CODEMAP.
> This only happends when ILOAD_Folding happens and find corresponding
> chi/phi is dead.
> 2. After SSA::Create_CODEMAP, rename coderep if dead chi/phi node is revive
> in CODEMAP setup.
>
> Different with fixing in DSE to mark first chi node live, this fix not
> affect DSE, so not affect performance.
> And this is verified with spec2006.rate on xeon.
>
> Regards
> Shi Hui
>
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
>
>
> _______________________________________________
> Open64-devel mailing
> listOpen64-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/open64-devel
>
>
>
------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
Open64-devel mailing list
Open64-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/open64-devel
