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 .
Ping...
the latest version of this patch was posted here:
https://gcc.gnu.org/ml/gcc-patches/2017-05/msg01758.html
Thanks
Bernd.
On 05/23/17 16:31, Bernd Edlinger wrote:
> Hi,
>
> this is the latest version of my patch.
>
> As already said, it attempts to compute
> the frame layout only when
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
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-tested successfully on
x86_64-pc-linux-gnu with uni
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
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, which is no longer necessary,
because the fram
29 matches
Mail list logo
