This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
| Other format: | [Raw text] | |
I still don;t. Just about every optimization deals with up to date stmts. You have to go out of your way not to, like the renamer and DOM.
In any case, if an optimization is dealing with out of date stmts, then it ought to be manipulating the trees directly since the operand cache isn't being used, not using FOR...OPERAND. Its for use when the normal rules are being followed.
Checking for SSA_NAME within the body serves no real purpose. If you are operating in an out-of-date state where you can get a non-ssa name, then you are in a state where you are likely missing information by using FOR...OPERAND.
I don't disagree with this. I didn't write the code in question, and in fact I was the one that suggested it be changed. But i'll argue it's not clearly documented that they only return SSA_NAMES in places like tree-ssa.texi.
It only talks about operands. It's not clear that these operands can only be SSA_NAMES. Naming the iterator "FOR_EACH_SSA_TREE_OPERAND" instead of "FOR_EACH_SSA_NAME_OPERAND" doesn't really help :)
Andrew
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |