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 (
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 commit
> 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
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=217237&root=gcc&view=rev
Log:
PR target/63534
gcc/
* config/i386/i386.md (builtin_setjmp_receiver): Use
pic_offset_table_rtx for PIC
On Thu, Nov 6, 2014 at 5:01 AM, 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)
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 Evgeny
On 11/05/14 05:59, Evgeny Stupachenko wrote:
On Tue, Nov 4, 2014 at 1:40 AM, Jeff Law 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 shoul
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 better
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
PR target/63534
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 wrote:
> On Nov 1, 2014, at 5:39 AM, Evgeny Stupachenko wrote:
>> When PIC register is pseudo there is nothing s
On Tue, Nov 4, 2014 at 1:40 AM, Jeff Law 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
> 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 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
On Nov 1, 2014, at 5:39 AM, 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 o
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 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
PR target/63534
* config/i386/i386.c (bu
>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 perf
On Oct 17, 2014, at 7:08 AM, Evgeny Stupachenko 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 introduced
are fixed b
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
PR target/63534
* config/i386/i386.c (builtin_setjmp_receiver): Delete.
(nonlocal
19 matches
Mail list logo
