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: [PATCH, RFC]: Next stage1, refactoring: propagating rtx subclasses


On 05/04/2015 02:18 PM, Mikhail Maltsev wrote:
Yes, FWIW, it is only needed for assertions in peep2_regno_dead_p and
peep2_reg_dead_p which check it against NULL (they are intended to
verify that live_before field in peep2_insn_data struct is valid). At
least, when I removed the assertions and changed PEEP2_EOB to NULL (as
an experiment), the testsuite passed without regressions.

You'd probably be better off creating a unique rtx_insn * object and
using that as the marker.
OK. Fixed the patch. Rebased and tested on x86_64-linux (fortunately, it
did not conflict with Trevor's series of rtx_insn-related patches).
Thanks for taking care of that.


I'm trying to continue and the next patch (peep_split.patch,
peep_split.cl) is addressing the same task in some of the generated code
(namely, gen_peephole2_* and gen_split_* series of functions).
And that looks good. If it's bootstrapping and regression testing then it's good to go too.


If you're going to continue this work, you should probably get
write-after-approval access so that you can commit your own approved
changes.
Is it OK to mention you as a maintainer who can approve my request for
write access?
Yes, absolutely. If you haven't already done so, go ahead and get this going because...

Both patches are approved.  Please install onto the trunk.

jeff


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