On Fri, Oct 21, 2011 at 2:43 PM, nathan binkert <[email protected]> wrote:
> I actually don't think it's that hard to follow, but I agree that it's
> strange.
I don't even think it's that strange, once you get over the fact that I used
the forbidden word. Or maybe, to put it another way, the strangeness is
only because people aren't used to seeing that word used. The code
certainly ended up the way it did because that's exactly the way I thought
of the logic operating: there's a common if/else decision, but there's one
weird case where even though you started out on the if side you discover
that you really wanted to do the else thing.
> I think a common way to write this would be to use a flag
> variable that's false to start, gets set to true in the one place, and
> then replace the } else { chunk of code with an if (flag) {
>
Yea, that's exactly what I did (though my flag has the opposite sense). It
works, but I wouldn't say it's clearer, and it does require an additional
test of the flag that isn't in the original code.
> > You are right that goto can have a negative impact on compiler
> optimization,
> > but if you're spending a measurable fraction of your runtime calling
> mmap()
> > then you have bigger problems than suboptimal simulation speed.
> That depends. If you use goto to replace normal looping stuff, yes,
> but if in the end, you need to replace the goto with a bunch of extra
> if-statements, it may not matter.
>
It's not a given that it has a negative impact, but I've heard that
when gcc sees a goto it just gives up on control-flow analysis, which could
have secondary effects in terms of which other optimizations get run. Not
sure if that's even true, but it seems plausible.
Steve
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
