This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: birthpoints in rtl.
- From: Jan Hubicka <hubicka at ucw dot cz>
- To: Kenneth Zadeck <zadeck at naturalbridge dot com>
- Cc: Diego Novillo <dnovillo at google dot com>, Steven Bosscher <stevenb dot gcc at gmail dot com>, gcc <gcc at gcc dot gnu dot org>, "Bonzini, Paolo" <bonzini at gnu dot org>, "Park, Seongbae" <seongbae dot park at gmail dot com>, Ian Lance Taylor <iant at google dot com>, Richard Sandiford <rsandifo at nildram dot co dot uk>
- Date: Sat, 1 Mar 2008 11:03:06 +0100
- Subject: Re: birthpoints in rtl.
- References: <47C5EF2A.5020401@naturalbridge.com> <47C6B132.3090903@naturalbridge.com> <47C88C6B.8030809@google.com> <571f6b510802291604t6ba0d302uc1a6bda69a7f807@mail.gmail.com> <47C89EC3.7030109@google.com> <47C8B3BB.4000801@naturalbridge.com>
> The two complications are:
> 1) libcalls
I am probably dense here, but why we can't just ignore existence of
libcalls for dataflow framework? This exist so we can effectivly remove
blocks of code in dead code removal and do some other changes, but I
don't see how they can be less friendly to FUD than they are to DU/UD.
Sure the optimization has to care to not break the extra invariant that
libcalls stay independent, but that is.
Overall yes, I certainly would hope they can go. Just I don't see direct
dependency with this project.
> 2) how do you merge different types of subregs stores.
>
> We have our best people working on (1) and the hope is that unless
> someone adds a killer reason to enhancement bugzilla 35413, we should be
> able to make that abomination go away forever. I plan to clear
> enhancement bugzilla 35404 this weekend.
>
> I am still hoping for one of the subreg elite to volunteer to help me
> with (2).
Subregs don't seem to be too different here. The reads of subregs are
equivalent with any other use. The stores are bit funnier since some
cases (subregs of multiword pseudos or STRICT_LOW_PART) behave as read
write operations. Only problem here seems to be that wihtout lowering
the multiword operation we have some extra uses of undefined variables
but this conservative handling should be good enough for most cases.
For introducing the PHI operations you do not need to worry if the value
originated in SUBREG or not.
Honza
>
> Then my plan is to "adapt" as much of the tree ssa code (there is no
> reason for me to write dominance frontier code for the 4 time from
> scratch) as possible to inserting the noop moves where the phi would
> normally go and adapt the renaming step to build the chains. I have not
> read the fud papers closely, but reif's trick of using for using the
> birthpoints means that you can actually avoid having to solve reaching
> defs, and can just adapt the ssa stack based renaming algorithm to build
> the chains rather than rename the vars. I have no idea if wolfe ever
> figured this part out or not.
>
> Kenny