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: pr52543

Ian is certainly correct.

I think that the question is really bigger than finding the correct line to fix. The problem is, that this code assumes that machines do not have multiword moves or multiword shifts. My machine has both, and i assume that the avr and the neon have at least multiword moves (but i do not know about the shifts). And as life moves forward, more machines will have these.

It seems like the right way to fix this is to somehow enhance the code at the beginning of decompose_multiword_subregs to ask which modes are not cheap to move or shift and then modify the second loop to never lower for those operations for those modes.

The question is do i add 2 more target hooks (one for shifting and one for moves) or do i use the rtx_cost mechanism and split for anything over COSTS_N_INSNS (1) or some such?


On 03/20/2012 01:13 AM, Ian Lance Taylor wrote:
Kenneth Zadeck<> writes:

I have figured out what the root cause of pr52543, but i need some
advise as to how to fix it.
The bug only happens if the source or destination of the move is a
hard register.   lower-subreg never breaks up pseudo to pseudo moves
that are larger than word mode.   According to richard sandiford, this
bug also appears on the neon, but i do not know if there is a bugzilla
for it.   It also appears on my private port, which is why i am
interested in it.

in the particular case of pr52543 and my port, this happens because
the input arguments are hard regs.

The offending code is in can_decompose_p.   The problem is that if the
reg is a hard reg, it completely blows off all of the information that
it accumulated during the first pass and unconditionally splits the
register (assuming it is legal to do so).

My question for the list, what is the predicate that we want to
replace the code that always  decomposes hardregs (assuming it is
legal).    In the case of the neon and my port, decomposing costs 4x
more than using a wide move.   I assume the avr is similar.
I don't think can_decompose_p would be the right thing to change.  If
that function returns false, resolve_simple_move is still going to split
up the move.  You need to change resolve_simple_move.  In fact, looking
at resolve_simple_move, I don't think it will break up the register
unless it has already decided to do so:

   /* If we didn't have any big SUBREGS of decomposed registers, and
      neither side of the move is a register we are decomposing, then
      we don't have to do anything here.  */

   if (src == SET_SRC (set)
       &&  dest == SET_DEST (set)
       &&  !resolve_reg_p (src)
       &&  !resolve_subreg_p (src)
       &&  !resolve_reg_p (dest)
       &&  !resolve_subreg_p (dest))
       end_sequence ();
       return insn;

So I think you need to analyze this a bit more.  I don't think that is
the offending code.


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