On 11/05/14 05:59, Evgeny Stupachenko wrote:
On Tue, Nov 4, 2014 at 1:40 AM, Jeff Law <l...@redhat.com> wrote:
On 11/01/14 06:39, Evgeny Stupachenko wrote:
When PIC register is pseudo there is nothing special about it's
value that setjmp can hurt. So if the pseudo register lives
across setjmp_receiver RA should care about correct allocation
(in case it is not saved/restored, it should go on stack). gcc.dg
tests and specs I've tested behave like this.
If the allocator picked a call-clobbered register for the PIC
register, then we're obviously OK since the setjmp has to be
expected to clobber the PIC register.
But if the PIC register is in a call-saved register, then it's
going to be assumed to not be clobbered across calls and I don't
believe that is guaranteed for builtin setjmp/longjmp. Those
restore SP, FP and an ARGP, but not anything else by default.
I still don't see what is special for PIC register here. PIC pseudo
now behave as every other pseudo register. If we assume that setjmp
can change a pseudo register value we need IRA/LRA "magic" for each
pseudo register.
And that's precisely what we have as Eric pointed out. Any allocnos
that are live across calls are not allocated into hard registers if we
call setjmp or can receive a nonlocal goto.
I believe that when we had EBX fixed, IRA/LRA don't save/restore it
anywhere. Therefore we had to care about EBX value in special cases
like setjmp/non-local goto. Now RA cares about PIC pseudo as well as
about correct allocation for any pseudo register.
Right. But what was missing was the explanation why this change is
correct. With the knowledge about how IRA handles objects under these
circumstances that Eric pointed to, it becomes much easier to see that
the special handling is no longer desirable.
? You mean it emits a reference to the pseudo into RTL? That
would indicate that the allocators never put the pseudo into a hard
register?!? RTL dumps with a few pointers to key insns would help
here.
Correct, that is why Darwin crashes with ICE on non-local goto. We
still have:
I was referring to the generated RTL to confirm what I thought you
stated, namely that we ended up with a reference to the pseudo being
emitted into the insn stream after reload.
The only way I could see that happening would be if the pseudo wasn't
allocated a hard register at all. Which we now know makes sense after
Eric pointed us the magic in ira-lives.c.
In the end it all comes down to what is the behaviour of the allocator
for a value that is live across calls in these kinds of functions.
I think I've got enough background to properly review now ;-)
Jeff
