This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: Swap optimization pass
Jeffrey A Law writes:
> I wonder if regmove might be another place we could try to attack
> this problem instead of creating another pass. I'm a little worried
> that regmove is becoming a place to stick random unrelated optimizations,
> but it might still make more sense than creating a new pass.
It seems like GCC requires an optional pass to combine insns that
don't appear to be directly related by data flow, such as the swap
insn. This pass would be especially useful to combine seemingly
independent insns for targets that have multi-pack instructions.
While on the topic of the combiner, at the beginning of try_combine
there appears the following...
/* If any of I1, I2, and I3 isn't really an insn, we can't do anything.
This can occur when flow deletes an insn that it has merged into an
auto-increment address. We also can't do anything if I3 has a
REG_LIBCALL note since we don't want to disrupt the contiguity of a
libcall. */
if (GET_RTX_CLASS (GET_CODE (i3)) != 'i'
|| GET_RTX_CLASS (GET_CODE (i2)) != 'i'
|| (i1 && GET_RTX_CLASS (GET_CODE (i1)) != 'i')
|| find_reg_note (i3, REG_LIBCALL, NULL_RTX))
return 0;
Why is this test for the REG_LIBCALL note necessary since i3 won't
be deleted by the combiner? Alternatively, could we allow i2 to be
combined with i3 having a REG_LIBCALL note if i1 is 0 and i2 is
PREV_INSN(i3) (or even prev_active_insn(i3))? This would provide
better register allocation for targets where arguments are passed
in registers.
Michael.