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
This is a new version of the original 4/6 shrink wrapping patch, minus
the preliminary bits that were already approved, and with some extra bug
fixes that were discovered in the meantime. This is now mostly contained
to just function.c. I'll resubmit the other parts (i.e. exposing more
shrink-wrapp
41 matches
Mail list logo
