Re: RFC: expand from SSA form (1/2)

[Andrew MacLeod <amacleod at redhat dot com>]

Michael Matz wrote:
> > Has there been any thought to turning mudflap into a plugin now that we 
> > have the machinery for that? Its seems like a ripe candidate.
> >     
>
> At least not from my side.  I went the sissy way and instead fixed mudflap 
> to work on SSA form :-|
>
>   
Which is also what I would have done :-)

> Yeah, I'm not terribly fond of the iteration above either.  I somehow
> wanted to avoid walking all SSA names to set this to-be-invented flag,
> but I also didn't want to slow the partition unioning by merging the 
> flags.  I probably bite the apple and create a new bitmap per partition
> as you suggested.
>
>   
I wasn't thinking of doing it in the unioning, but after coalescing was 
done. I figured that since you end up walking each element of each 
partition checking for default defs, it should be a similar cost to 
simply loop over each ssa_version after coalescing, check for 
default_def, and set a bit for the owning partition. or something like that.

>   
>
> Thinking about it now I see a way to solve it.  Simply not advancing the
> iterator when we have something to insert should do the trick.  Still
> doesn't explain why commit_edge_insertions should work.
>   
>   
As richi says, perhaps its just never had sufficient opportunity... odd 
but possible.

Maybe it could be fixed in commit_edge_insertions, and have the initial 
part of that routine factored out since that exactly what you are doing 
here as well, and simply call the 'fixed' factored routine.

That should count as a future bug fixed :-)

> > > !   result = (* pp1)->cost - (* pp2)->cost;
> > >     /* Since qsort does not guarantee stability we use the elements
> > >       
> > 	 as a secondary key.  This provides us with independence from
> > 	 the host's implementation of the sorting algorithm.  */
> >
> > Hmm. how long has this been backwards... 
> > its seems fine in 4.2, I rewrote it for 4.3, and jeez, its been backwards
> > since 4.3.0 was released it seems.  Zoinks.
> >     
>
> :-)  It's a bit non-obvious, because the predicate looks correct at
> first sight and only becomes incorrect considering that the sorted array
> then is walked from back to front ;)
>   
Speaking of bugs fixed.  Yeah, well, it was immediately obvious to me 
when I looked at a sample and the list of coalesces comes out in the 
same order as the low-to-high cost list in .optimized.  I guess I never 
noticed the forest through the trees. Man that's lame.

Andrew