This is the mail archive of the gcc-patches@gcc.gnu.org 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: [PR64164] drop copyrename, integrate into expand


On Mar 31, 2015, Richard Biener <richard.guenther@gmail.com> wrote:

>> +                     || !(SSA_NAME_IS_DEFAULT_DEF (var)
>> +                          || (param_defaults
>> +                              && bitmap_bit_p (param_defaults, part))))

> This looks somewhat awkward to me ;)  Is it really important to allow
> coalescing PARM_DECL-based SSA vars with sth else?

It's a valid optimization.  I can't say it's really important, but if
the only objection is to param_defaults, I'm getting rid of it.

> At least abnormal coalescing doesn't need to do that, so just walking
> over the function decls parameters and making their default-def live
> should be enough?

It should.  We'd have to duplicate logic of parameters, including static
chain and whatnot.  I figured this would make it more resilient to
changes elsewhere.

>> +      else if (TREE_CODE (SSA_NAME_VAR (var2)) == VAR_DECL)
>> +       leader = SSA_NAME_VAR (var2);
>> +      else /* What else could it be?  */
>> +       gcc_unreachable ();
>> +

> definitely comments missing in this spaghetti...

I'm trying to remove the spaghetting now.

> or seeing this, why coalesce default-defs at all?

Why not?  (the referenced code is gone from my local tree, BTW)

> Either they are param values or they have indetermined values (and
> thus we can and do pick whatever is available at expansion time)?

If they are param values, we want to have them available; if they
aren't, whatever we coalesce with is good.


> So the above does full coalescing ignoring conflicts.

Yeah.  We want to tell what we'd get if all coalesce possibilities are
taken, so that we can assign the same basevar to all partitions so that
we detect conflicts.

> Did you do any statistics on how the number of basevars changes with your patch
> compared to trunk?

'fraid I didn't run any statistics whatsoever.  I didn't think it was
important, since it's pretty much just doing copyrename during coalesce.
Truth be told, this has since relaxed some of the constraints from
copyrename, and I'm going to relax some more in the next iteration, so I
guess some statistics wouldn't be a bad idea.  Is there any specific
testcase you're interested in, or something like a GCC bootstrap or
somesuch?

-- 
Alexandre Oliva, freedom fighter    http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer


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