Why are BLOCK_HEAD/BLOCK_END not used?

Why are BLOCK_HEAD/BLOCK_END not used?

[Steven Bosscher]

Hello,

For tree-ssa I would like to make the basic block head/end a union because we 
now have a head and end for both RTL and trees, and obviously we only can use 
one at a time so one field at least is redundant.

Problem is, everything uses bb->head instead of BLOCK_HEAD (bb), and bb->end 
instead of BLOCK_END (bb).  Is there a reason for this?  Would a patch to 
update _all_ of these to use the macro be acceptable in stage3 if it prevents 
merge trouble for the tree-ssa branch maintainers?

Gr.
Steven

[RFC] Use accessor macros for the head and end of a basic block

[Steven Bosscher]

[-- Attachment #1: Type: text/plain, Size: 2486 bytes --]

On Monday 08 December 2003 16:30, Steven Bosscher wrote:
> Hello,
>
> For tree-ssa I would like to make the basic block head/end a union because
> we now have a head and end for both RTL and trees, and obviously we only
> can use one at a time so one field at least is redundant.
>
> Problem is, everything uses bb->head instead of BLOCK_HEAD (bb), and
> bb->end instead of BLOCK_END (bb).  Is there a reason for this?  Would a
> patch to update _all_ of these to use the macro be acceptable in stage3 if
> it prevents merge trouble for the tree-ssa branch maintainers?

Of course the BLOCK_HEAD and BLOCK_END macros aren't the right ones. We'd need 
two new macros...

(BLOCK_{HEAD,END} are hardly used, and it seems that at least in reload we 
could use a pointer to a basic block instead of an int in insn_chain.  But 
that's for later.)

Now, here's the change I'd like to make.  This is probably already the largest 
patch I've ever submitted, but it should have no effect whatsoever.  
Basically all this does is replace all occurences of "<bb>->{head,end}" with 
"BB_{HEAD,END} (<bb>).
(Diego, this is one of those changes I was talking about last week, and as you 
can see it touched matter all over the map.)

This patch does not convert all files at once, because this was a large (and 
RSI-prone ;-) amount of work, I'm extremely lazy and if this is unacceptable 
then I won't have to do the rest of them.

If a patch like this is not OK for mainline at this stage, then some CFG work 
that I had in mind for tree-ssa (putting will have to be postponed until 
after 3.4 branches.  But really, I'd like to put this in now because:
1. It is quite safe.
2. Not doing it makes it very impractical to make basic_block_def a bit
   smaller for tree-ssa, where this is needed especially now that we
   have a garbage collectable CFG.

Opinions? Should I finish this patch or is this just a big no-no?

Gr.
Steven

	* basic-block.h (BLOCK_HEAD, BLOCK_END): Remove.
	(BLOCK_HEAD_TREE, BLOCK_END_TREE): Remove.
	(BB_HEAD, BB_END): New accessor macros for the `head' and `end' fields
	of a basic_block.
	* bb-reorder.c, bt-load.c, caller-save.c, cfg.c, cfganal.c, cfgbuild.c,
	cfgcleanup.c, cfglayout.c, cfgloop.c, cfgloopanal.c, cfgloopmanip.c, 
	cfgrtl.c, combine.c, conflict.c, df.c, emit-rtl.c, gcse.c, haifa-sched.c,
	local-alloc.c, regmove.c, resource.c, sched-rgn.c: Use the BB_HEAD and
	BB_END macros instead of accessing the `head' and `end' fields of a
	basic block directly.

[-- Attachment #2: patch.gz --]
[-- Type: application/x-gzip, Size: 23895 bytes --]

Re: [RFC] Use accessor macros for the head and end of a basic block

[Jan Hubicka]

> On Monday 08 December 2003 16:30, Steven Bosscher wrote:
> > Hello,
> >
> > For tree-ssa I would like to make the basic block head/end a union because
> > we now have a head and end for both RTL and trees, and obviously we only
> > can use one at a time so one field at least is redundant.
> >
> > Problem is, everything uses bb->head instead of BLOCK_HEAD (bb), and
> > bb->end instead of BLOCK_END (bb).  Is there a reason for this?  Would a
> > patch to update _all_ of these to use the macro be acceptable in stage3 if
> > it prevents merge trouble for the tree-ssa branch maintainers?
> 
> Of course the BLOCK_HEAD and BLOCK_END macros aren't the right ones. We'd need 
> two new macros...
> 
> (BLOCK_{HEAD,END} are hardly used, and it seems that at least in reload we 
> could use a pointer to a basic block instead of an int in insn_chain.  But 
> that's for later.)

There are artefact of dark ages when it seemed to be good idea to
implement CFG using arrays AFAIK.
> 
> Now, here's the change I'd like to make.  This is probably already the largest 
> patch I've ever submitted, but it should have no effect whatsoever.  
> Basically all this does is replace all occurences of "<bb>->{head,end}" with 
> "BB_{HEAD,END} (<bb>).
> (Diego, this is one of those changes I was talking about last week, and as you 
> can see it touched matter all over the map.)
> 
> This patch does not convert all files at once, because this was a large (and 
> RSI-prone ;-) amount of work, I'm extremely lazy and if this is unacceptable 
> then I won't have to do the rest of them.
> 
> If a patch like this is not OK for mainline at this stage, then some CFG work 
> that I had in mind for tree-ssa (putting will have to be postponed until 
> after 3.4 branches.  But really, I'd like to put this in now because:
> 1. It is quite safe.
> 2. Not doing it makes it very impractical to make basic_block_def a bit
>    smaller for tree-ssa, where this is needed especially now that we
>    have a garbage collectable CFG.
> 
> Opinions? Should I finish this patch or is this just a big no-no?

I think it is right thing to do.  How will the tree counterparts called?
Perhaps we can use BLOCK_HEAD_RTL/BLOCK_HEAD_TREE to make naming more
conventient.

Honza

Re: [RFC] Use accessor macros for the head and end of a basic block

[law]

In message <20031208220915.GA32401@atrey.karlin.mff.cuni.cz>, Jan Hubicka write
s:
 >> Opinions? Should I finish this patch or is this just a big no-no?
 >
 >I think it is right thing to do.  How will the tree counterparts called?
 >Perhaps we can use BLOCK_HEAD_RTL/BLOCK_HEAD_TREE to make naming more
 >conventient.
I would _strongly_ recommend this go into the mainline first, otherwise
we're going to create a lot of gratutious changes which makes merging
(both to the branch and eventually to the mainline) a lot more work than
it ought to be.
jeff

Re: [RFC] Use accessor macros for the head and end of a basic block

[Steven Bosscher]

On Tuesday 09 December 2003 05:05, law@redhat.com wrote:
> I would _strongly_ recommend this go into the mainline first

Of course.  Where did I say [tree-ssa] in the subject line?

I take it you do not dislike the idea of putting this kind of patch on 
mainline in this stage?

Gr.
Steven

Re: [RFC] Use accessor macros for the head and end of a basic block

[law]

In message <200312090749.12424.steven@gcc.gnu.org>, Steven Bosscher writes:
 >On Tuesday 09 December 2003 05:05, law@redhat.com wrote:
 >> I would _strongly_ recommend this go into the mainline first
 >
 >Of course.  Where did I say [tree-ssa] in the subject line?
 >
 >I take it you do not dislike the idea of putting this kind of patch on 
 >mainline in this stage?
For mainline, I'm more than happy to leave it up to Mark :-)  I've got no
strong opinions there.


jeff

Re: [RFC] Use accessor macros for the head and end of a basic block

[Steven Bosscher]

[-- Attachment #1: Type: text/plain, Size: 1829 bytes --]

On Tuesday 09 December 2003 07:52, law@redhat.com wrote:
> In message <200312090749.12424.steven@gcc.gnu.org>, Steven Bosscher writes:
>  >On Tuesday 09 December 2003 05:05, law@redhat.com wrote:
>  >> I would _strongly_ recommend this go into the mainline first
>  >
>  >Of course.  Where did I say [tree-ssa] in the subject line?
>  >
>  >I take it you do not dislike the idea of putting this kind of patch on
>  >mainline in this stage?
>
> For mainline, I'm more than happy to leave it up to Mark :-)  I've got no
> strong opinions there.

Here is the full patch for mainline, bootstrapped (c,c++,objc,f77) and
checked on i686-pc-linux-gnu.  Very mechanical, in all.  I renamed the
head and end field to make sure no-one uses it again and gets away with
it unpunished...

OK for mainline?  Once it's there I'll do the same for tree-ssa.

        * basic-block.h (BLOCK_HEAD, BLOCK_END): Remove.
        (BLOCK_HEAD_TREE, BLOCK_END_TREE): Remove.
	(basic_block_def): Rename `head' to `head_' and `end' to `end_'.
        (BB_HEAD, BB_END): New accessor macros for the `head_' and `end_'
	fields of a basic block.
        * bb-reorder.c, bt-load.c, caller-save.c, cfg.c, cfganal.c,
	cfgbuild.c, cfgcleanup.c, cfglayout.c, cfgloop.c, cfgloopanal.c,
	cfgloopmanip.c, cfgrtl.c, combine.c, conflict.c, df.c, emit-rtl.c,
	final.c, flow.c, function.c, gcse.c, global.c, graph.c,
	haifa-sched.c, ifcvt.c, lcm.c, local-alloc.c, loop-unswitch.c,
	loop.c, postreload.c, predict.c, profile.c, ra-build.c, ra-debug.c,
	ra-rewrite.c, ra.c, recog.c, reg-stack.c, regclass.c, regmove.c,
	regrename.c, reload1.c, resource.c, sched-ebb.c, sched-rgn.c,
	sibcall.c, tracer.c, config/frv/frv.c, config/i386/i386.c,
	config/ia64/ia64.c: Use the BB_HEAD and BB_END macros instead of
	accessing the `head' and `end' fields of a basic block directly.

[-- Attachment #2: patch.gz --]
[-- Type: application/x-gzip, Size: 43837 bytes --]

Re: [RFC] Use accessor macros for the head and end of a basic block

[Zack Weinberg]

Steven Bosscher <steven@gcc.gnu.org> writes:

> On Tuesday 09 December 2003 07:52, law@redhat.com wrote:
>> In message <200312090749.12424.steven@gcc.gnu.org>, Steven Bosscher writes:
>>  >On Tuesday 09 December 2003 05:05, law@redhat.com wrote:
>>  >> I would _strongly_ recommend this go into the mainline first
>>  >
>>  >Of course.  Where did I say [tree-ssa] in the subject line?
>>  >
>>  >I take it you do not dislike the idea of putting this kind of patch on
>>  >mainline in this stage?
>>
>> For mainline, I'm more than happy to leave it up to Mark :-)  I've got no
>> strong opinions there.
>
> Here is the full patch for mainline, bootstrapped (c,c++,objc,f77) and
> checked on i686-pc-linux-gnu.  Very mechanical, in all.  I renamed the
> head and end field to make sure no-one uses it again and gets away with
> it unpunished...
>
> OK for mainline?  Once it's there I'll do the same for tree-ssa.

Since Mark is out of town, since this is extremely mechanical and low
risk, and since divergence between mainline and tree-ssa is
undesirable here, I am willing to approve this patch for mainline -
but it comes right back out again if it causes the slightest bit of
trouble, capische?

zw