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
- From: Zdenek Dvorak
- To: Richard Guenther
- Cc: Steven Bosscher , gcc-patches at gcc dot gnu dot org
- Date: Mon, 26 Feb 2007 11:19:38 +0100
- Subject: Re: [PATCH] Do not set BB_SUPERBLOCK in loop-unroll.c:split_edge_and_insert
- References: <200702250134.02861.steven@gcc.gnu.org> <20070225184955.GA13143@atrey.karlin.mff.cuni.cz> <571f6b510702251457h1a41099aw79b1223356c1ffc6@mail.gmail.com> <20070225231043.GA472@atrey.karlin.mff.cuni.cz> <571f6b510702251536h57560c1bgc8d7c8750d864a6a@mail.gmail.com> <84fc9c000702260214v73c50959j633f6e9761b06f83@mail.gmail.com>
Hello,
On 2/26/07, Steven Bosscher stevenb.gcc@gmail.com wrote:
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).
I have no problem with waiting, but I can also fix the problem if I have a test case (I have a hackish patch, in fact). All I really want to see is whether any test suite failures show up somewhere, so that we have this code covered in the test suite.
To be honest, I don't believe we'll have any test suite failures, or other problems. But right now I see no other way to make sure, than by just trying. When something breaks after all, we can revert the patch for the moment and I can work on a proper fix (and of course I'd appreciate your help, if possible). But I can only fix a problem properly if I know that there is a problem to begin with.
I really would not propose this unusual way forward if I would see a better way out...
I believe this is a reasonable way to go, if there's funny code in GCC nobody knows why it's there and there's no testcase you can come up with that breaks if removing it go ahead and remove it. In the end GCC will be better because we either removed some unneccesarry stuff or we finally get a testcase that breaks.
well, admitting that we have a code that we have no idea what it is doing, so we just disable it on hope that something breaks does not seem all that good to me. Yes, it is much simpler than reading the code and finding out what the hell is going on, but it just does not seem proper.
Zdenek
- References:
- [PATCH] Do not set BB_SUPERBLOCK in loop-unroll.c:split_edge_and_insert
* From: Steven Bosscher - Re: [PATCH] Do not set BB_SUPERBLOCK in loop-unroll.c:split_edge_and_insert
* From: Zdenek Dvorak - Re: [PATCH] Do not set BB_SUPERBLOCK in loop-unroll.c:split_edge_and_insert
* From: Steven Bosscher - Re: [PATCH] Do not set BB_SUPERBLOCK in loop-unroll.c:split_edge_and_insert
* From: Zdenek Dvorak - Re: [PATCH] Do not set BB_SUPERBLOCK in loop-unroll.c:split_edge_and_insert
* From: Steven Bosscher - Re: [PATCH] Do not set BB_SUPERBLOCK in loop-unroll.c:split_edge_and_insert
* From: Richard Guenther
- [PATCH] Do not set BB_SUPERBLOCK in loop-unroll.c:split_edge_and_insert
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |