So that code creates a set of conflicts which, if I'm reading correctly,
will prevent the PIC value from living in a register at all. Which
ought to result in it being dumped into the stack and being reloaded for
each use. Which ought to be safe (modulo the liveness bug Vlad is
working on
Hi Jeff,
On 7 Nov 2014, at 20:28, Jeff Law wrote:
On 11/06/14 06:01, Evgeny Stupachenko wrote:
Now I see that equiv reload could be special for PIC register. Let's
apply more conservative patch.
Darwin bootstrap passed with the patch applied on r216304 (along with
already committed to
On 11/08/14 09:16, Iain Sandoe wrote:
Hi Jeff,
On 7 Nov 2014, at 20:28, Jeff Law wrote:
On 11/06/14 06:01, Evgeny Stupachenko wrote:
Now I see that equiv reload could be special for PIC register.
Let's apply more conservative patch.
Darwin bootstrap passed with the patch applied on r216304
On 11/05/14 04:54, Eric Botcazou wrote:
Now if your argument is that IRA/LRA handle this, that's fine, a pointer
to that code would be appreciated so that it can be quickly audited.
Certainly the old local-alloc/global-alloc had magic for setjmp/longjmp
and maybe IRA/LRA does too, but it's
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
On 11/06/14 06:01, Evgeny Stupachenko wrote:
Now I see that equiv reload could be special for PIC register. Let's
apply more conservative patch.
Darwin bootstrap passed with the patch applied on r216304 (along with
already committed to trunk patches from PR63618 and PR63620).
2014-11-06
On Thu, Nov 6, 2014 at 5:01 AM, Evgeny Stupachenko evstu...@gmail.com wrote:
Now I see that equiv reload could be special for PIC register. Let's
apply more conservative patch.
Darwin bootstrap passed with the patch applied on r216304 (along with
already committed to trunk patches from
Thanks.
Committed to trunk with that fix:
Author: kyukhin
Date: Fri Nov 7 20:42:36 2014
New Revision: 217237
URL: https://gcc.gnu.org/viewcvs?rev=217237root=gccview=rev
Log:
PR target/63534
gcc/
* config/i386/i386.md (builtin_setjmp_receiver): Use
pic_offset_table_rtx for PIC
Now I see that equiv reload could be special for PIC register. Let's
apply more conservative patch.
Darwin bootstrap passed with the patch applied on r216304 (along with
already committed to trunk patches from PR63618 and PR63620).
2014-11-06 Evgeny Stupachenko evstu...@gmail.com
PR
Now if your argument is that IRA/LRA handle this, that's fine, a pointer
to that code would be appreciated so that it can be quickly audited.
Certainly the old local-alloc/global-alloc had magic for setjmp/longjmp
and maybe IRA/LRA does too, but it's better to be sure than just assume.
See
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
We don't emit extra SET_GOT. That is beneficial.
As for stack usage, that is RA to decide which register is more
beneficial to put on stack.
On Sat, Nov 1, 2014 at 8:33 PM, Mike Stump mikest...@comcast.net wrote:
On Nov 1, 2014, at 5:39 AM, Evgeny Stupachenko evstu...@gmail.com wrote:
When PIC
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).
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.
On Nov 1, 2014, at 5:39 AM, Evgeny Stupachenko evstu...@gmail.com 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,
On 10/17/14 08:08, Evgeny Stupachenko wrote:
Hi,
The patch fixes 1st fail in darwin bootstarp.
When PIC register is pseudo we don't need to init it after setjmp or
non local goto.
Is it ok?
ChangeLog:
2014-10-17 Evgeny Stupachenko evstu...@gmail.com
PR target/63534
*
For example, is the pic register saved and restored?
Yes, if RA decided that it is better to save it.
If restored, is the code to save it actually better than simply appearing it
out of thin air as did previously?
enabling ebx gives performance mostly to loops. There still could be
some
Hi,
The patch fixes 1st fail in darwin bootstarp.
When PIC register is pseudo we don't need to init it after setjmp or
non local goto.
Is it ok?
ChangeLog:
2014-10-17 Evgeny Stupachenko evstu...@gmail.com
PR target/63534
* config/i386/i386.c (builtin_setjmp_receiver):
On Oct 17, 2014, at 7:08 AM, Evgeny Stupachenko evstu...@gmail.com wrote:
The patch fixes 1st fail in darwin bootstarp.
When PIC register is pseudo we don't need to init it after setjmp or
non local goto.
Is it ok?
So, I don’t see commentary in the PR that all fallout and all bugs
19 matches
Mail list logo
