On 10/06/2011 02:39 PM, Bernd Schmidt wrote:
> * function.c (frame_required_for_rtx): Remove function.
> (requires_stack_frame_p): New arg set_up_by_prologue. All callers
> changed. Compute a set of mentioned registers and compare against
> the new arg rather than calling
On 10/06/11 21:33, Ian Lance Taylor wrote:
> Note that you can test Go yourself by adding --enable-languages=go to
> your configure line. Nothing special is required to build Go. It works
> better if you use the gold linker but that is not required.
Oh, ok. For some reason I thought I was remem
Bernd Schmidt writes:
> On 10/06/11 17:57, Ian Lance Taylor wrote:
>> There is absolutely no reason to try to shrink wrap that code. It will
>> never help. That code always has to be first. It especially has to be
>> first because the gold linker recognizes the prologue specially when a
>> spl
On Thu, Oct 6, 2011 at 11:40 AM, Bernd Schmidt wrote:
> On 10/06/11 20:27, H.J. Lu wrote:
>> It also caused:
>>
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50633
>>
>> Don't you need to update ix86_expand_prologue?
>
> In theory it should just work. It seems the x32 stuff has entertaining
> pro
On 10/06/11 20:27, H.J. Lu wrote:
> It also caused:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50633
>
> Don't you need to update ix86_expand_prologue?
In theory it should just work. It seems the x32 stuff has entertaining
properties :-( Haven't quite figured out how to build it yet, but:
On Tue, Oct 4, 2011 at 3:10 PM, Bernd Schmidt wrote:
> On 09/30/11 18:51, Richard Henderson wrote:
>
>> Please do leave out RETURN_ADDR_REGNUM for now. If you remember why,
>> then you could bring it back alongside the patch for the ARM backend.
>
> Changed.
>
>> As for the i386 backend changes,
On 10/06/11 20:13, Richard Henderson wrote:
> What PR are you looking at here?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50632
Testcase is gcc.dg/pr50132.c.
Bernd
On 10/06/2011 11:03 AM, Bernd Schmidt wrote:
> HJ found some more maybe_record_trace_start failures. In one case I
> debugged, we have
>
> (insn/f 31 0 32 (parallel [
> (set (reg/f:DI 7 sp)
> (plus:DI (reg/f:DI 7 sp)
> (const_int 8 [0x8])))
>
HJ found some more maybe_record_trace_start failures. In one case I
debugged, we have
(insn/f 31 0 32 (parallel [
(set (reg/f:DI 7 sp)
(plus:DI (reg/f:DI 7 sp)
(const_int 8 [0x8])))
(clobber (reg:CC 17 flags))
(clobber (mem:BL
On 10/06/2011 09:01 AM, Bernd Schmidt wrote:
> On 10/06/11 17:57, Ian Lance Taylor wrote:
>> There is absolutely no reason to try to shrink wrap that code. It will
>> never help. That code always has to be first. It especially has to be
>> first because the gold linker recognizes the prologue sp
On 10/06/11 17:57, Ian Lance Taylor wrote:
> There is absolutely no reason to try to shrink wrap that code. It will
> never help. That code always has to be first. It especially has to be
> first because the gold linker recognizes the prologue specially when a
> split-stack function calls a non-
Bernd Schmidt writes:
> On 10/06/11 05:17, Ian Lance Taylor wrote:
>> Thinking about it I think this is the wrong approach. The -fsplit-stack
>> code by definition has to wrap the entire function and it can not modify
>> any callee-saved registers. We should do shrink wrapping before
>> -fsplit
On 10/06/2011 06:37 AM, Bernd Schmidt wrote:
> On 10/06/11 01:47, Bernd Schmidt wrote:
>> This appears to be because the split prologue contains a jump, which
>> means the find_many_sub_blocks call reorders the block numbers, and our
>> indices into bb_flags are off.
>
> Testing of the patch compl
On 10/06/11 01:47, Bernd Schmidt wrote:
> This appears to be because the split prologue contains a jump, which
> means the find_many_sub_blocks call reorders the block numbers, and our
> indices into bb_flags are off.
Testing of the patch completed - ok? Regardless of split-stack it seems
like a c
On 10/06/11 05:17, Ian Lance Taylor wrote:
> Thinking about it I think this is the wrong approach. The -fsplit-stack
> code by definition has to wrap the entire function and it can not modify
> any callee-saved registers. We should do shrink wrapping before
> -fsplit-stack, not the other way arou
Bernd Schmidt writes:
> This appears to be because the split prologue contains a jump, which
> means the find_many_sub_blocks call reorders the block numbers, and our
> indices into bb_flags are off.
>
> I'm testing the following patch, but it won't finish today - feel free
> to test and check it
On 10/06/11 01:04, Ian Lance Taylor wrote:
> On Wed, Oct 5, 2011 at 10:17 AM, Bernd Schmidt
> wrote:
>>
>> I've committed the following after a x86_64-linux bootstrap.
>
> This patch appears to have broken the Go bootstrap when compiling a C
> file in libgo. Here is a reduced test case:
>
> st
On Wed, Oct 5, 2011 at 10:17 AM, Bernd Schmidt wrote:
>
> I've committed the following after a x86_64-linux bootstrap.
This patch appears to have broken the Go bootstrap when compiling a C
file in libgo. Here is a reduced test case:
static struct
{
int n;
unsigned int m;
_Bool f;
} g;
_B
On 10/05/2011 10:19 AM, Bernd Schmidt wrote:
> * function.c (thread_prologue_and_epilogue_insns): Don't shrink-wrap
> if profiling after the prologue.
Ok.
r~
On 10/05/11 00:29, Richard Henderson wrote:
> As a followup, I think this option needs to be disabled for profiling
> and profile_after_prologue. Should be a mere matter of frobbing the
> options at startup.
The other code seems to test crtl->profile rather than an option flag,
so how's this? Boo
On 10/05/11 18:21, Richard Henderson wrote:
> On 10/05/2011 08:59 AM, Bernd Schmidt wrote:
>> Bootstrapping the following now. Ok? (Alternatively, could keep the
>> redzone logic, but make it depend on !flag_shrink_wrap).
>
> It's a good space-saving optimization, that redzone logic. We
> should
On 10/05/2011 08:59 AM, Bernd Schmidt wrote:
> Bootstrapping the following now. Ok? (Alternatively, could keep the
> redzone logic, but make it depend on !flag_shrink_wrap).
It's a good space-saving optimization, that redzone logic. We
should be able to keep it based on crtl->shrink_wrapped; that
On 10/05/11 17:13, Richard Guenther wrote:
> On Wed, Oct 5, 2011 at 12:29 AM, Richard Henderson wrote:
>> On 10/04/2011 03:10 PM, Bernd Schmidt wrote:
>>> * doc/invoke.texi (-fshrink-wrap): Document.
>>> * opts.c (default_options_table): Add it.
>>> * common.opt (fshrink-wrap): A
On Wed, Oct 5, 2011 at 12:29 AM, Richard Henderson wrote:
> On 10/04/2011 03:10 PM, Bernd Schmidt wrote:
>> * doc/invoke.texi (-fshrink-wrap): Document.
>> * opts.c (default_options_table): Add it.
>> * common.opt (fshrink-wrap): Add.
>> * function.c (emit_return_into_block
On 10/04/2011 03:10 PM, Bernd Schmidt wrote:
> * doc/invoke.texi (-fshrink-wrap): Document.
> * opts.c (default_options_table): Add it.
> * common.opt (fshrink-wrap): Add.
> * function.c (emit_return_into_block): Remove useless declaration.
> (record_hard_reg_uses_1, r
On 09/30/11 18:51, Richard Henderson wrote:
> Please do leave out RETURN_ADDR_REGNUM for now. If you remember why,
> then you could bring it back alongside the patch for the ARM backend.
Changed.
> As for the i386 backend changes, not an objection per se, but I'm
> trying to understand why we n
On 10/03/11 13:28, Basile Starynkevitch wrote:
> Regarding this shrink-wrapping patch, I would suggest to describe, in a
> comments of one or two sentences, what shkink-wrapping means in the context
> of GCC.
See the documentation part of the patch.
Bernd
Hello,
Regarding this shrink-wrapping patch, I would suggest to describe, in a
comments of one or two sentences, what shkink-wrapping means in the context
of GCC.
http://en.wikipedia.org/wiki/Shrink_wrap does not help much in understanding
that.
Cheers.
--
Basile STARYNKEVITCH http://s
Just a suggestion, but...
Bernd Schmidt writes:
> Index: gcc/cfgcleanup.c
> ===
> --- gcc/cfgcleanup.c (revision 178734)
> +++ gcc/cfgcleanup.c (working copy)
> @@ -1488,6 +1488,16 @@ outgoing_edges_match (int mode, basic_bl
>e
On 09/27/2011 02:02 PM, Bernd Schmidt wrote:
> Here's a new version of the entire shrink-wrapping patch with the
> trap_if test replaced by the outgoing_edges_match change, the condjump_p
> bug fixed, and the dump output and testcase adjusted a bit. Bootstrapped
> and tested on i686-linux and mips-
On 09/15/11 00:51, Richard Henderson wrote:
> On 09/13/2011 08:36 AM, Bernd Schmidt wrote:
>> On 09/13/11 15:05, Richard Sandiford wrote:
>>> It just feels like checking for trap_if or turning off cross-jumping
>>> are working around problems in the representation of shrink-wrapped
>>> functions.
On 09/13/2011 08:36 AM, Bernd Schmidt wrote:
> On 09/13/11 15:05, Richard Sandiford wrote:
>> It just feels like checking for trap_if or turning off cross-jumping
>> are working around problems in the representation of shrink-wrapped
>> functions. There should be something in the IL to say that th
On 09/13/11 15:05, Richard Sandiford wrote:
> It just feels like checking for trap_if or turning off cross-jumping
> are working around problems in the representation of shrink-wrapped
> functions. There should be something in the IL to say that those
> two blocks cannot be merged for CFI reasons.
Bernd Schmidt writes:
> On 09/13/11 13:37, Richard Sandiford wrote:
>> Bernd Schmidt writes:
>>> On 09/13/11 10:35, Richard Sandiford wrote:
> Also, it turns out I need to pretend that trap_if requires the prologue
> due to the testcase you also ran across, so a for_each_rtx walk is
>
On 09/13/11 13:37, Richard Sandiford wrote:
> Bernd Schmidt writes:
>> On 09/13/11 10:35, Richard Sandiford wrote:
Also, it turns out I need to pretend that trap_if requires the prologue
due to the testcase you also ran across, so a for_each_rtx walk is
required anyway.
>>>
>>> Why
Bernd Schmidt writes:
> On 09/13/11 10:35, Richard Sandiford wrote:
>>> Also, it turns out I need to pretend that trap_if requires the prologue
>>> due to the testcase you also ran across, so a for_each_rtx walk is
>>> required anyway.
>>
>> Why does TRAP_IF inherently need a prologue though? Th
On 09/13/11 10:35, Richard Sandiford wrote:
>> Also, it turns out I need to pretend that trap_if requires the prologue
>> due to the testcase you also ran across, so a for_each_rtx walk is
>> required anyway.
>
> Why does TRAP_IF inherently need a prologue though? The CFA information
> should be
Bernd Schmidt writes:
>>> +/* Return true if INSN requires the stack frame to be set up.
>>> + PROLOGUE_USED contains the hard registers used in the function
>>> + prologue. */
>>> +static bool
>>> +requires_stack_frame_p (rtx insn, HARD_REG_SET prologue_used)
>>> +{
>>> [...]
>>> + if (for_
On 09/01/11 15:57, Richard Sandiford wrote:
> add_to_hard_reg_set (pused, GET_MODE (x), REGNO (x));
Done.
> Strange line break, and comment doesn't match code (no "changed" variable).
Fixed.
>> +/* Return true if INSN requires the stack frame to be set up.
>> + PROLOGUE_USED contains the hard
Bernd Schmidt writes:
> +/* A for_each_rtx subroutine of record_hard_reg_sets. */
> +static int
> +record_hard_reg_uses_1 (rtx *px, void *data)
> +{
> + rtx x = *px;
> + HARD_REG_SET *pused = (HARD_REG_SET *)data;
> +
> + if (REG_P (x) && REGNO (x) < FIRST_PSEUDO_REGISTER)
> +{
> + in
40 matches
Mail list logo
