This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]