On Tue, May 23, 2017 at 4:31 PM, Bernd Edlinger
wrote:
> Hi,
>
> this is the latest version of my patch.
>
> As already said, it attempts to compute
> the frame layout only when relevant data have
> changed.
>
> Apologies for doing more clean-up on Daniel's
> patch than absolutely necessary, but .
On 05/23/2017 09:31 AM, Bernd Edlinger wrote:
Hi,
this is the latest version of my patch.
As already said, it attempts to compute
the frame layout only when relevant data have
changed.
Apologies for doing more clean-up on Daniel's
patch than absolutely necessary, but ...
Bootstrap and reg-tes
On 05/22/2017 01:32 PM, Bernd Edlinger wrote:
On 05/19/17 05:17, Daniel Santos wrote:
No, I'm not at all comfortable with you making so many seemingly
unnecessary changes to this code. (Although I wish I got this much
feedback during my RFCs! :) I can accept the changes to
is/count_stub_manag
On 05/19/17 05:17, Daniel Santos wrote:
> On 05/18/2017 08:37 AM, Bernd Edlinger wrote:
>> On 05/17/17 04:01, Daniel Santos wrote:
- if (ignore_outlined && cfun->machine->call_ms2sysv
- && in_hard_reg_set_p (stub_managed_regs, DImode, regno))
-return false;
+ if (igno
PS: Oh! it might be due to the difference between -j1 and no -j argument.
Yes, that's how I missed it. This flaw isn't exposed with make -j1, but
is exposed with just make. Thanks for finding this!
Daniel
On 05/18/2017 08:37 AM, Bernd Edlinger wrote:
On 05/17/17 04:01, Daniel Santos wrote:
- if (ignore_outlined && cfun->machine->call_ms2sysv
- && in_hard_reg_set_p (stub_managed_regs, DImode, regno))
-return false;
+ if (ignore_outlined && cfun->machine->call_ms2sysv)
+{
+ /* R
On 05/17/17 04:01, Daniel Santos wrote:
>>
>> - if (ignore_outlined && cfun->machine->call_ms2sysv
>> - && in_hard_reg_set_p (stub_managed_regs, DImode, regno))
>> -return false;
>> + if (ignore_outlined && cfun->machine->call_ms2sysv)
>> +{
>> + /* Registers who's save & restor
On 05/17/2017 01:39 PM, Bernd Edlinger wrote:
On 05/15/17 03:39, Daniel Santos wrote:
I should add that if you want to run faster tests just on the ms to sysv
abi code, you can use make RUNTESTFLAGS="ms-sysv.exp" check and then if
that succeeds run the full testsuite.
Daniel
Hmm, that's funn
On 05/17/2017 12:41 PM, Bernd Edlinger wrote:
Apologies if I ruined your patch...
As I said before, I'm the new guy here. :) So when this is done I'll
rebase my changes. I have some test stuff to fix and some refactoring
and refinements to xlogue_layout::compute_stub_managed_regs(). And then
On 05/15/17 03:39, Daniel Santos wrote:
> On 05/14/2017 11:31 AM, Bernd Edlinger wrote:
>> Hi Daniel,
>>
>> there is one thing I don't understand in your patch:
>> That is, it introduces a static value:
>>
>> /* Registers who's save & restore will be managed by stubs called from
>> pro/epilogu
On 05/17/17 04:01, Daniel Santos wrote:
> On 05/16/2017 02:52 PM, Bernd Edlinger wrote:
>> I think I solved the problem with -fsplit-stack, I am not sure
>> if ix86_static_chain_on_stack might change after reload due to
>> final.c possibly calling targetm.calls.static_chain, but if that
>> is the c
On 05/16/2017 02:52 PM, Bernd Edlinger wrote:
I think I solved the problem with -fsplit-stack, I am not sure
if ix86_static_chain_on_stack might change after reload due to
final.c possibly calling targetm.calls.static_chain, but if that
is the case, that is an already pre-existing problem.
The g
On 05/16/2017 12:19 PM, Ian Lance Taylor wrote:
On Mon, May 15, 2017 at 10:00 PM, Daniel Santos wrote:
Ian, would you mind looking at this please? A combination of my
-mcall-ms2sysv-xlogues patch with Bernd's patch is causing problems when
ix86_expand_split_stack_prologue() calls ix86_expand_c
On 05/16/17 21:52, Bernd Edlinger wrote:
> The calls_eh_return and ix86_static_chain_on_stack may become
> known at a later time, but after reload it should not change any more.
> To be sure, I added an assertion at ix86_static_chain, which the
> regression test did not trigger, neither with -m64 n
On 05/16/17 19:19, Ian Lance Taylor wrote:
> On Mon, May 15, 2017 at 10:00 PM, Daniel Santos
> wrote:
>>
>> Ian, would you mind looking at this please? A combination of my
>> -mcall-ms2sysv-xlogues patch with Bernd's patch is causing problems when
>> ix86_expand_split_stack_prologue() calls ix86
On Mon, May 15, 2017 at 10:00 PM, Daniel Santos wrote:
>
> Ian, would you mind looking at this please? A combination of my
> -mcall-ms2sysv-xlogues patch with Bernd's patch is causing problems when
> ix86_expand_split_stack_prologue() calls ix86_expand_call().
I don't have a lot of context here.
On 05/16/2017 03:34 AM, Bernd Edlinger wrote:
It would be good to have test cases for each of the not-supported warnings that
can happen, so far I only managed to get a test case for -fsplit-stack.
Yes, I'm inclined to agree. I'll try to get this done today or
tomorrow. I've also put in a li
On 05/16/2017 07:00, Daniel Santos wrote:
>
> Ian, would you mind looking at this please? A combination of my
> -mcall-ms2sysv-xlogues patch with Bernd's patch is causing problems when
> ix86_expand_split_stack_prologue() calls ix86_expand_call().
Here is what I am testing currently.
I fixed the
Ian, would you mind looking at this please? A combination of my
-mcall-ms2sysv-xlogues patch with Bernd's patch is causing problems when
ix86_expand_split_stack_prologue() calls ix86_expand_call().
On 05/15/2017 06:46 PM, Daniel Santos wrote:
Rather or not m->call_ms2sysv is set determines whi
On 05/15/2017 03:39 PM, Bernd Edlinger wrote:
On 05/15/17 03:39, Daniel Santos wrote:
On 05/14/2017 11:31 AM, Bernd Edlinger wrote:
Hi Daniel,
there is one thing I don't understand in your patch:
That is, it introduces a static value:
/* Registers who's save & restore will be managed by stubs
On 05/15/17 03:39, Daniel Santos wrote:
> On 05/14/2017 11:31 AM, Bernd Edlinger wrote:
>> Hi Daniel,
>>
>> there is one thing I don't understand in your patch:
>> That is, it introduces a static value:
>>
>> /* Registers who's save & restore will be managed by stubs called from
>> pro/epilogu
On 05/14/2017 11:31 AM, Bernd Edlinger wrote:
Hi Daniel,
there is one thing I don't understand in your patch:
That is, it introduces a static value:
/* Registers who's save & restore will be managed by stubs called from
pro/epilogue. */
static HARD_REG_SET GTY(()) stub_managed_regs;
This
On 05/14/2017 11:31 AM, Bernd Edlinger wrote:
Hi Daniel,
there is one thing I don't understand in your patch:
That is, it introduces a static value:
/* Registers who's save & restore will be managed by stubs called from
pro/epilogue. */
static HARD_REG_SET GTY(()) stub_managed_regs;
This
Hi Daniel,
there is one thing I don't understand in your patch:
That is, it introduces a static value:
/* Registers who's save & restore will be managed by stubs called from
pro/epilogue. */
static HARD_REG_SET GTY(()) stub_managed_regs;
This seems to be set as a side effect of ix86_compute
On Sun, May 14, 2017 at 11:16 AM, Daniel Santos wrote:
> On 05/14/2017 02:42 AM, Bernd Edlinger wrote:
>>
>> Hi,
>>
>>
>> this patch uses the new TARGET_COMPUTE_FRAME_LAYOUT hook in the i386
>> backend to avoid re-computing the frame layout when not really
>> necessary.
>>
>> It simplifies the log
On 05/14/2017 02:42 AM, Bernd Edlinger wrote:
Hi,
this patch uses the new TARGET_COMPUTE_FRAME_LAYOUT hook in the i386
backend to avoid re-computing the frame layout when not really
necessary.
It simplifies the logic in ix86_compute_frame_layout by removing
the use_fast_prologue_epilogue_nregs
26 matches
Mail list logo
