This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: reload1: detect chained reloads
> Sure, but rld[i].in loops over all the reloads, doesn't it?
Oh, right.
> 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.
Yup. It's the same basic problem, but I need a solution for m32c to
work robustly. I'm not particular about what that solution is.
> 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.
It's a compare of two mems, the address of one of which is stored in
the frame, beyond the displacement of the frame pointer. So, all
three are input reloads of one sort or another. I don't know why
they're getting the types they are; I can send you my working patches
so you can reproduce the problem if you're interested in looking at
it.
It only seems to fail for regex.c. If I try to simplify it, it ends
up figuring out how to get things into the right registers. There
seems to be some "critical complexity" required before it keeps enough
things on the stack.