Zdenek Dvorak - Re: [PATCH] Do not set BB_SUPERBLOCK in loop-unroll.c:split_edge_and_ins (original) (raw)

This is the mail archive of the gcc-patches@gcc.gnu.orgmailing 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]

Re: [PATCH] Do not set BB_SUPERBLOCK in loop-unroll.c:split_edge_and_insert


Hello,

On 2/25/07, Zdenek Dvorak rakdver@atrey.karlin.mff.cuni.cz wrote:

I do not dare to approve this; introducing code that relies on "blackbox" understanding of what some functions do seems a bit dangerous to me.

I don't understand this concern.

This is stage1. If something breaks, I can fix it.

I am more worried about the case when nothing breaks now, and in four years, someone will be really unhappy about having to decipher this hack. Unless you fix the problem properly now, somebody else will have to do it later, and you seem to have already spent some time on investigating the problem.

I would love to say that I will fix the problem for you, and perhaps I will, if you are willing to wait for about two weeks (before I get rid of some other work that pilled on me just now).

Although it may be quite difficult, I think that the only clean way is to find out why force_operand/compare_and_jump_seq do not emit control flow insns when they are used as in loop-unroll.c, and base a solution on this (which may turn out to be just extending the patch below by documenting in which cases these functions are guaranteed not to introduce control flow insns).

I have no intention to do this. You added this line and even you wrote at the time that you were not sure why it is needed.

Did I? I added this code years ago, and I do not remember the exact testcase(s) that lead me to it, but I would hope I did not do it without a reason (I am lazy enough).

Testing on more than half a dozen targets shows no breakage at all. I have called for help on this issue and got almost no reply. I am not going to invest time in describing hypothetical corner cases.

Well, if these corner cases do not really appear, why cannot you also remove the code in force_operand/compare_and_jump_seq that appears that it could generate them?

Zdenek


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]