Hello Ian,
One example is:
insn X : "REG_X = <expression>"
insn X+1 : "MEM(addr) = REG_X"
insn X+2 : "REGY:CCmode compare(REG_X, const_int 0)"
generated by C code (already posted by me some weeks ago):
------
int a, b, c, d;
int foo()
{
a += b;
if(a)
c = d;
}
Insns X+2 and X can usually be combined because arithmetic operation
usually sets condition codes.
After some hours of debug I noticed combine pass never tries to insert
insn X+2 into insn insn X just because destination insn must be after
the source insn.
Also, combine pass only try to combine the reg setter and its first
user (as far as I understood), which is not the case (comparison is the
second REG_X user).
I tried to make try_combine to accept an insn destination that is
before (insn list order) than insn source, but after fixing a SEG FAULT
on can_combine_p I noticed subst didn't the expected job on insn X+2 and
insn X.
If insn X+2 is placed just after insn X, combine can insert insn X into
insn X+2 and generate just one insn.
So, changing the insn order seems to be simpler than changing combine
pass too deeply.
thanks for the hint on df_ functions.
Alex R. Prado
Em 27/04/2011 14:43, Ian Lance Taylor < i...@google.com > escreveu:
cirrus75 writes:
> I am trying to improve combine pass (for all backends). One approach
is changing the order of some insns before combine pass starts. The first
problem I have is about the REGNOTES, they need to be rebuilt after
changing insn order. Does anyone know how to do that ?
It's not clear to me why changing insn order will help combine. Can you
give us an example?
In current mainline, the regnotes are added at the start of the combine
pass by df_note_add_problem and df_analyze at the start of
rest_of_handle_combine (please do not ask why it works this way). So if
you reshuffle the insns in a pass before combine, and handle DF
information appropriately, then you don't have to worry about the
regnotes at all.
Ian
