A volatile variable cannot be involved in much optimization without
affecting correctness. E.g. a CSE involving a volatile variable deletes
a use, which is wrong. The defs and uses of a volatile variable must be
preserved at their original places. Since SSA is for performing
optimizations, it is OK NOT to put volatile variables in SSA form.
Since zero versioning is also for variables not in SSA form, volatile
variables are treated like zero versions. This means all appearances of
volatile variables are always assigned SSA version zero.
Since we have to keep track of all aliasing to avoid illegal
optimizations, we have to keep track of aliases with volatile variables.
Thus, the zero version of volatile variables can appear in mu/chi. The
comment that "volatiles do not appear in any mu and chi" is probably not
accurate, but the code is correct. I would adjust the comment to
"unnecessary to maintain volatile variables' mu/chi lists".
Virtual variables are for SSA representation. Thus, virtual variables
are never volatile.
I just put forth the principles. Hope this helps answer your specific
questions.
Fred
On 02/17/2014 10:37 PM, Jian-Xin Lai wrote:
Hi,
Basically, the volatile symbol shouldn't appear in the mu and chi. For
example, in osprey/be/opt/opt_revise_ssa.cxx, we can find the
following code:
933 // this loop for pre-existing variables
934 IDX_32_SET_ITER iter;
935 iter.Init(_symbols_to_revise);
936 for (i = iter.First_elem(); ! iter.Is_Empty(); i =
iter.Next_elem()) {
937 if (i >= _first_new_aux_id)
938 break;
939 if (_opt_stab->Aux_stab_entry(i)->Is_volatile())
940 continue; // volatiles do not appear in any mu and chi
941 Update_chi_list_for_old_var(stmt, i);
942 }
943
944 // this loop for new variables
945 for (i = _first_new_aux_id; i <= _opt_stab->Lastidx(); i++) {
946 if (_opt_stab->Aux_stab_entry(i)->Is_volatile())
947 continue; // volatiles do not appear in any mu and chi
948 Insert_mu_and_chi_list_for_new_var(stmt, i);
949 }
But I do find in some other places, there are code to handle the
volatile symbol in mu/chi list:
opt_dce.cxx, BOOL DCE::Required_stmt(const STMTREP *stmt) const
2168 FOR_ALL_NODE(cnode, chi_iter, Init(stmt->Chi_list())) {
......
2175 // Fix 621039: mark statement affecting a volatile accesses
to be live
2176 if (Opt_stab()->Aux_stab_entry(cnode->Aux_id())->Is_volatile())
2177 return TRUE;
2178 }
opt_find.cxx, void CODEMAP::Fix_zero_version(CHI_NODE *chi, STMTREP *stmt)
884 // Fix 815093: Set volatile flag
885 if ( Opt_stab()->Is_volatile( chi_opnd->Aux_id() ) ) {
886 retval->Set_is_volatile();
887 }
And in opt_verify.cxx, I also find the following comments from Raymond
in the code:
670 // The aux symbol table allows volatile variables that are
virtual variable
671 // to be entered into the mu/chi list. Real volative variables
are not
672 // entered though. It is inconsistent and should be clean
up. After the
673 // cleanup, changes in be/opt/opt_remame -r1.5 can be backed out.
674 // -Raymond 6/24/98.
I'm confuced by the code and comments above. My questions are,
1. What will the "consistent approach" look like?
2. Can the volatile symbol appear in mu/chi regardless it's virtual or
not? If it's not allowed, how to represent the side effect for a
iload/istore on volatile symbols? Can it always use the default vsym?
Thank you very much.
--
Regards,
Lai Jian-Xin
------------------------------------------------------------------------------
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
_______________________________________________
Open64-devel mailing list
Open64-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/open64-devel
------------------------------------------------------------------------------
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
_______________________________________________
Open64-devel mailing list
Open64-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/open64-devel
