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: reload1: detect chained reloads


DJ Delorie <dj@redhat.com> writes:

> > Do you have any other CPU you can do a bootstrap on?  You're not
> > likely to see a lot of RELOAD_FOR_OPERAND_ADDRESS reloads on x86_64.
> 
> Well, that's the problem, nobody else is likely to have this kind of
> problem.  The only other port with this kind of reload issue is m68k,
> and they admit they maintain their own patches so I don't expect the
> unchanged fsf gcc to be a realistic test.

I doubt anybody else will have this problem, but there are other
processors which do at least use RELOAD_FOR_OPERAND_ADDRESS, and thus
might exercise your code a bit.

> > This just doesn't look right.  For one thing, rld[i].in may be NULL.
> 
> For RELOAD_FOR_OPERAND_ADDRESS?  That's the only time this is called.

Sure, but rld[i].in loops over all the reloads, doesn't it?

> > And what if you get something along the lines of (plus (mem (reg r))
> > (plus (mem (reg r)) (const_int 1))) The fact that the same value
> > appers in rld[].in for both reloads doesn't imply that they are
> > related, and I don't see why it is OK to assume that they won't both
> > be needed at the same time.
> 
> Well, what I'm trying to solve is like (mem (mem (reg))).  Reload is
> currently using two different registers for each address.  I need it
> to use one, like this:
> 
> 	mov	<reg>,a0
> 	mov	[a0],a0
> 	mov	[a0],a0
> 
> I could be more specific in my tests, if I knew more about reload.

I understand that that is the issue.  To me it seems to tie back to
something we discussed before, that for each *_ADDRESS reload we want
to know the specific reload for which we are holding the address.
Then we can know that there is no conflict.  Without that information
it seems difficult to be sure.

Incidentally, when I ran into this type of issue myself, for the
MIPS16, I invented RELOAD_FOR_INPADDR_ADDRESS and
RELOAD_FOR_OUTADDR_ADDRESS to permit more separation in
reload_conflict.  So, why do you get RELOAD_FOR_OPERAND_ADDRESS for
both of your reloads?  Why isn't one of them
RELOAD_FOR_INPADDR_ADDRESS or at least RELOAD_FOR_OPADDR_ADDR?  No
doubt there is some horrible answer.

Ian


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