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]

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]