On Mar 4, 2008, Kenneth Zadeck <[EMAIL PROTECTED]> wrote:
> Richard Sandiford wrote:
>> If we went for an explicit move, I assume we would either have to
>> (a) discount hard regs that can't be moved, (b) force backends to
>> allow all no-op moves or (c) circumvent the backend somehow.
> From my
On 3/4/08 4:06 PM, Jan Hubicka wrote:
The names are equivalent to UD pointers: Either you can have version
names or just coinsider the destination of UD pointer to be the
destination. Or am I still missing a point?
Nope, that's exactly right. Versioned names are useful for some things
(mos
> > I think that at this point, i have been convinced to:
> >
> > 1) use fud's rather than birthpoints because these do keep a slot for
> > the value along each in edge.
> > 2) keep the info on the side (see rsandifors diverging thread).
> >
> > I am not there on keeping extra names on the side.
> I think that at this point, i have been convinced to:
>
> 1) use fud's rather than birthpoints because these do keep a slot for
> the value along each in edge.
> 2) keep the info on the side (see rsandifors diverging thread).
>
> I am not there on keeping extra names on the side. The advantag
On Tue, Mar 4, 2008 at 9:46 PM, Richard Sandiford
<[EMAIL PROTECTED]> wrote:
> I don't see why hard registers are special as far as FUD chains go.
> We have DU chains for hard regs, so why not FUDs too?
We have them, but does anyone use them? Does anyone actually even
compute them? (Apparently
"Steven Bosscher" <[EMAIL PROTECTED]> writes:
> On Tue, Mar 4, 2008 at 8:47 PM, Richard Sandiford
> <[EMAIL PROTECTED]> wrote:
>> "Steven Bosscher" <[EMAIL PROTECTED]> writes:
>> Going back to something discussed upthread: would you expect to use this
>> for hard regs as well as pseudos? No-op m
Jan Hubicka wrote:
> Hi,
>
>> 1) In ssa, the operands of the phis and the renaming contain
>> information. The operands are paired with the cfg edges that the
>> values come in on. In fud/birthpoints there is no such pairing or
>> renaming. For some problems, like conditional constant, thi
Hi,
>
> 1) In ssa, the operands of the phis and the renaming contain
> information. The operands are paired with the cfg edges that the
> values come in on. In fud/birthpoints there is no such pairing or
> renaming. For some problems, like conditional constant, this pairing
> and renaming is
On Tue, Mar 4, 2008 at 8:47 PM, Richard Sandiford
<[EMAIL PROTECTED]> wrote:
> "Steven Bosscher" <[EMAIL PROTECTED]> writes:
> Going back to something discussed upthread: would you expect to use this
> for hard regs as well as pseudos? No-op moves aren't necessarily supported
> for all hard reg
On 3/4/08 2:38 PM, Kenneth Zadeck wrote:
Steven Bosscher wrote:
On Tue, Mar 4, 2008 at 7:58 PM, Diego Novillo <[EMAIL PROTECTED]> wrote:
Both PHIs and birthpoints are merely factoring devices that let you cut
down the number of UD links. They don't need to be part of the IL, much
like no
Richard Sandiford wrote:
> "Steven Bosscher" <[EMAIL PROTECTED]> writes:
>
>> For the location of the extra instructions, I would *not* keep them on
>> the side. If you have something special going on, my motto is: "Make
>> it explicit".
>>
>
> Going back to something discussed upthread: w
"Steven Bosscher" <[EMAIL PROTECTED]> writes:
> For the location of the extra instructions, I would *not* keep them on
> the side. If you have something special going on, my motto is: "Make
> it explicit".
Going back to something discussed upthread: would you expect to use this
for hard regs as w
Steven Bosscher wrote:
> On Tue, Mar 4, 2008 at 7:58 PM, Diego Novillo <[EMAIL PROTECTED]> wrote:
>
>> Both PHIs and birthpoints are merely factoring devices that let you cut
>> down the number of UD links. They don't need to be part of the IL, much
>> like none of the DF objects are part of
On 3/4/08 2:12 PM, Steven Bosscher wrote:
That code is IMHO just awfully ugly. And slow too, last I checked.
Yeah, there's quite a bit of bookkeeping needed to do incremental SSA
updates.
should not want that on RTL. I don't think we should allow
transformations on RTL that are too hard t
On Tue, Mar 4, 2008 at 7:58 PM, Diego Novillo <[EMAIL PROTECTED]> wrote:
> Both PHIs and birthpoints are merely factoring devices that let you cut
> down the number of UD links. They don't need to be part of the IL, much
> like none of the DF objects are part of the RTL IL.
Maybe they don't ne
On Sat, Mar 1, 2008 at 11:13 AM, Jan Hubicka <[EMAIL PROTECTED]> wrote:
> > Diego,
> >
> > I am leaning to just adding noop moves at the birthpoints (dominance
> > frontiers) as real noop move insns in the streams in the passes that use
> > ud or du chains. The back end is tolerant of noop mo
On 3/4/08 1:53 PM, Steven Bosscher wrote:
So, from an implementation, would we make PHI-like UD-chains to nop
insns that represent the birth points, or would we actually add PHI
functions and let the "normal" UD-chains point to the PHI function
arguments?
Why put them in the IL stream at all?
On Sat, Mar 1, 2008 at 2:46 PM, Paolo Bonzini <[EMAIL PROTECTED]> wrote:
>
> > By the way, I still don't understand how birth points would work. Can
> > someone give an example of what the insn stream would look like with
> > birth points, and what the DU/UD chains would look like?
>
> With a
And there's another special-case treatment for libcalls. On top of
REG_LIBCALL/REG_RETVAL/REG_LIBCALL_ID. This is bug prone. For GCC 4.3
alone, I've fixed half a dozen libcall blocks related bugs, and others
have fixed at least as many. Not to mention all the extra work they
caused for the peop
On Sat, Mar 1, 2008 at 3:01 PM, Diego Novillo <[EMAIL PROTECTED]> wrote:
> On 2/29/08 10:01 PM, Kenneth Zadeck wrote:
>
> > it is more productive to spend the cycles getting rid of the libcalls
> > rather than figuring out the edge cases. as steven implied, we have
> > been on the verge of get
On 3/1/08 5:13 AM, Jan Hubicka wrote:
while I am with Diego that would preffer PHI nodes on side especially in
FUD chain where rest of your SSA is on side too. But if we go with the
extra instruction scheme, I think you are much better to use RTL USE
instruction. The moves are generated by tar
On 2/29/08 10:01 PM, Kenneth Zadeck wrote:
it is more productive to spend the cycles getting rid of the libcalls
rather than figuring out the edge cases. as steven implied, we have
been on the verge of getting rid of them for years and just have just
not fixed the last reason. The amount of
On 3/1/08 8:50 AM, Paolo Bonzini wrote:
Yes, that's what I meant by "no subscripts" (see also my other message
re. birthpoints). Instead of subscripting variables you have multiple
defs for each variable. End each def is obviously assigned only once,
and each use in the IL stream except for
Diego Novillo wrote:
On 2/29/08 7:04 PM, Steven Bosscher wrote:
I am not sure what would happen if GCC would start using FUD chains.
Is it like in SSA that every register is assigned only once?
But this would only affect the UD chains built by the DF code.
Yes, that's what I meant by "no su
By the way, I still don't understand how birth points would work. Can
someone give an example of what the insn stream would look like with
birth points, and what the DU/UD chains would look like?
With a big IIUC, and using a high-level IR for simplicity
if (a < 5) goto BB1; else goto BB2;
>
> Not libcalls, but libcall *notes*.
>
> > 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
On Sat, Mar 1, 2008 at 11:03 AM, Jan Hubicka <[EMAIL PROTECTED]> wrote:
> > The two complications are:
> > 1) libcalls
>
> I am probably dense here, but why we can't just ignore existence of
> libcalls for dataflow framework?
Not libcalls, but libcall *notes*.
> This exist so we can effectiv
> Diego,
>
> I am leaning to just adding noop moves at the birthpoints (dominance
> frontiers) as real noop move insns in the streams in the passes that use
> ud or du chains. The back end is tolerant of noop moves and without
Hi,
while I am with Diego that would preffer PHI nodes on side espec
> 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 F
Diego Novillo wrote:
> What if you treated subregs as total writes (like we do arrays) and
> libcalls as clobbering points? Though I guess that may not be
> sufficient.
>
>
it is more productive to spend the cycles getting rid of the libcalls
rather than figuring out the edge cases. as steven
On Fri, Feb 29, 2008 at 20:39, Kenneth Zadeck <[EMAIL PROTECTED]> wrote:
> I personally dislike the fact that the middle end keeps the phi's separate.
Six of one, half a dozen of the other. If you put the PHIs in the IL
stream, then you need to be careful about not moving anything before
or in
Diego Novillo wrote:
> On 2/29/08 7:04 PM, Steven Bosscher wrote:
>
>> I am not sure what would happen if GCC would start using FUD chains.
>> Is it like in SSA that every register is assigned only once?
>
> But this would only affect the UD chains built by the DF code. My
> idea is to build the s
On 2/29/08 7:04 PM, Steven Bosscher wrote:
I am not sure what would happen if GCC would start using FUD chains.
Is it like in SSA that every register is assigned only once?
But this would only affect the UD chains built by the DF code. My idea
is to build the same UD chains, but make them sp
On Fri, Feb 29, 2008 at 11:51 PM, Diego Novillo <[EMAIL PROTECTED]> wrote:
> If we are not going to use a rewriting SSA form, I believe that the
> original problems we had with RTL-SSA can be avoided.
The nice thing about birth points would be that most RTL optimizers
can look through NOPs (amaz
On 2/28/08 8:03 AM, Kenneth Zadeck wrote:
The big difference between what i am proposing with birthpoints and a
full blown ssa implementation is that i plan to do no rewriting since
there are no operands of the phis to support this.
You don't need to do a rewriting SSA implementation to have P
On 2/28/08 8:59 AM, Jan Hubicka wrote:
Yes, I do believe that wast majority of DU/UD code can stay as it is.
We just need to introduce the PHI nodes, either in a way Gimple does
that in separate section of CFG or as real RTL noop moves (or we can
even have RTL PHI code that would behave same way
On 2/27/08 6:15 PM, Kenneth Zadeck wrote:
Comments? Volunteers?
How about adding FUD chains instead of the dense UD chains we have
today? FUD chains are almost trivial to port from gimple-ssa into RTL.
We already overlay a use-def web on the RTL representation using the new
dataflow bits.
On 2/28/08 8:32 AM, Paolo Bonzini wrote:
FUD chains are basically SSA without subscripts -- and hence, without
overlapping live ranges.
No, they have subscripts. They just do not have OLRs.
Diego.
On 28 Feb 2008 13:52:56 -0800, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> I think it's probably a blocker issue on 32-bit x86 until we complete
> the lower subreg work to track subreg lifetimes to detect no-conflict
> sections manually. I have an implementation of that written before
> DF,
"Steven Bosscher" <[EMAIL PROTECTED]> writes:
> On 28 Feb 2008 12:41:30 -0800, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> > libcalls are still used for no-conflict blocks. This may be what you
> > mean by the scheduling thing. No-conflict blocks are emitted by
> > emit_no_conflict_block an
On 28 Feb 2008 12:41:30 -0800, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> libcalls are still used for no-conflict blocks. This may be what you
> mean by the scheduling thing. No-conflict blocks are emitted by
> emit_no_conflict_block and checked in local-alloc.
I thought the no-conflict bl
"Steven Bosscher" <[EMAIL PROTECTED]> writes:
> On Thu, Feb 28, 2008 at 2:32 PM, Paolo Bonzini <[EMAIL PROTECTED]> wrote:
> >
> > > Thanks for the quick response. As it turns out, the libcall issue will
> > > soon be gone, as bonzini will be deleting them. We have finally
> > > overcome that
Steven Bosscher wrote:
> On Thu, Feb 28, 2008 at 2:32 PM, Paolo Bonzini <[EMAIL PROTECTED]> wrote:
>
>> > Thanks for the quick response. As it turns out, the libcall issue will
>> > soon be gone, as bonzini will be deleting them. We have finally
>> > overcome that issue.
>>
>> Not really.
On Thu, Feb 28, 2008 at 2:32 PM, Paolo Bonzini <[EMAIL PROTECTED]> wrote:
>
> > Thanks for the quick response. As it turns out, the libcall issue will
> > soon be gone, as bonzini will be deleting them. We have finally
> > overcome that issue.
>
> Not really. There seems always to be somethi
> My real point in starting this discussion was to try to interest
> (sucker) one of the subreg specialists into helping me solve the issue
> of inserting move at the birthpoint where subregs or strict lower values
> are used.
I don't see your problem here. Any use (as in reading) of a
subreg ca
Andrew MacLeod wrote:
> Kenneth Zadeck wrote:
>>
>> Birthpoints are not nearly as useful as phi-functions because the
>> algorithms that use birthpoints do not generally leave the birthpoints
>> in the right places when they are finished. There is a lot of value
>> added by the operand of phi-func
Kenneth Zadeck wrote:
Birthpoints are not nearly as useful as phi-functions because the
algorithms that use birthpoints do not generally leave the birthpoints
in the right places when they are finished. There is a lot of value
added by the operand of phi-functions. But they do solve the n**2
c
Hi,
as discussed briefly on IRC yesterday, I would be very happy to see
current DU/UD infrastructure changed to FUD chains (or on side SSA
form). This way it will be more symmetric to how tree level virtual
operands are handled and will hopefully make whole compiler more
standard and easier to foll
Thanks for the quick response. As it turns out, the libcall issue will
soon be gone, as bonzini will be deleting them. We have finally
overcome that issue.
Not really. There seems always to be something that prevents them from
being deleted, and I have no time to spend on GCC at work righ
Jeff,
Thanks for the quick response. As it turns out, the libcall issue will
soon be gone, as bonzini will be deleting them. We have finally
overcome that issue.
The subregs are clearly going to be the issue, and before i dive into it
i want to understand what it means to do a merge a bunch of
On Feb 27, 2008, Kenneth Zadeck <[EMAIL PROTECTED]> wrote:
> The appeal for birthpoints is that unlike the abortive attempt in
> the past to add SSA to RTL, adding a noop moves does not really mess
> up anything.
IIRC, when people tried to do RTL SSA, the problem was with match_dups
in IN/OUT ope
I want to start a discussion about some possible changes to the RTL
level of GCC.
This discussion is motivated by some of the issues raised in bug
26854. We have addressed many of the issues in this bug, but the
remaining issue is cost, in both time and space, for the UD and DU
chains built by se
52 matches
Mail list logo
