This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [tree-ssa] Use of build_binary_op
On 26 Sep 2002 16:08:42 +0200, Steven Bosscher <s.bosscher@student.tudelft.nl> wrote:
> Op do 26-09-2002, om 15:02 schreef Jason Merrill:
>> On 26 Sep 2002 13:30:17 +0200, Steven Bosscher <s.bosscher@student.tudelft.nl> wrote:
>> > I'm not suggesting you optimize each statement. I'm suggesting we just
>> > leave it to the front end to decide where break/goto elimination (or
>> > some other transformation) is appropriate. The front end knows much
>> > better when such a transformation is useful.
>>
>> I disagree. Why would the frontend know better?
>
> Because (in this particular case) the front end knows that it introduces
> a goto that can be eliminated without getting into trouble with
> overlapping goto's and other unpleasant things. The middle end would
> first have to figure that out somehow.
If it's a test and goto at the beginning of the loop to a label immediately
after the loop, this isn't a hard case to recognize.
But actually, we can't eliminate that goto; a goto is the only way to get
out of a LOOP_EXPR. When I started out, I was using an EXIT_EXPR for the
loop condition, but that seems like unnecessary duplication. We need to
retain one of the gotos out of a loop, but it doesn't necessarily need to
be the one which came from the condition.
>> I don't think saving one walk over the whole tree is worth the loss in
>> abstraction.
>
> So do you think we should always do goto/break elimination for GIMPLE
> (or GENERIC) then? If so, when and for what constructs should we use it?
> In other words: How will the middle end know when these transformations
> are useful and not too hard to do?
Heuristics, built up over time. I'd start with not eliminating any gotos,
and then experiment to see what helps and what doesn't.
> In general, I do not believe that "whole function" goto/break
> elimination is a very useful transformation in most cases. Doing the
> transformations on big trees is expensive, and sometimes it does more
> harm than good.
> (ref. http://www.sable.mcgill.ca/~hendren/ftp/erosa/thesis.ps.gz).
Yes, I agree.
> Having said that, I guess trying to make loops have regular CFGs is
> almost always a good thing. Also, I'm all for abstraction and regular
> flow graphs, and I'm not sure what the best solution is...
Heuristics, built up over time. :)
Jason