On 04/13/2011 02:38 PM, Bernd Schmidt wrote:
> This still requires the i386 output_set_got which I think I can cope
> with [...]
Patch below, to be applied on top of all the others. Only lightly tested
so far beyond standard (fairly useless) regression tests, by comparing
generated assembly before
The final part, an updated version of the old 004-dw2cfg patch. This
does much better placement of remember/restore; in almost all cases the
code is identical to what we currently generate, modulo minor
differences around the PROLOGUE_END label. I've made it emit queued
register saves before PROLOG
The second part is a new patch, which reduces the amount of different
code paths we can take in add_fde_cfi, as this was becoming
unmanageable. The concept is to first emit just the CFI notes, in all
cases. Later, after we're done producing the CFI insns we need, another
pass over the rtl adds the
On 04/13/2011 04:14 PM, Bernd Schmidt wrote:
> On 04/11/2011 07:10 PM, Richard Henderson wrote:
>> Ok.
>
> Did you receive my reply to this message from earlier today? It doesn't
> seem to have made it to gcc-patches yet.
Since gcc-patches appears to have dropped the message, I'll resend it in
th
On Wed, Apr 13, 2011 at 07:44:26AM -0700, Richard Henderson wrote:
> Yeah, while I was working on dwarf line numbers recently, I found that
> just about the only thing that would produce anything interesting was
> a profiled bootstrap.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48253#c1
is what
On 04/13/2011 05:38 AM, Bernd Schmidt wrote:
> This bootstraps and tests ok on i686-linux. However, there is work left
> to be done. Can I take you up on your offer to work with me on this?
> This still requires the i386 output_set_got which I think I can cope
> with, but the ia64 backend does a nu
On 04/11/2011 07:10 PM, Richard Henderson wrote:
> Ok.
Did you receive my reply to this message from earlier today? It doesn't
seem to have made it to gcc-patches yet.
Bernd
On 04/05/2011 02:58 PM, Bernd Schmidt wrote:
> * dwarf2out.c (struct dw_cfi_struct): Remove member dw_cfi_next.
> (dw_cfi_ref): Add DEF_VEC_P and some DEF_VEC_ALLOC_Ps.
> (cfi_vec): New typedef.
> (struct dw_fde_struct): Make dw_fde_cfi a cfi_vec. Replace
> dw_fde_swit
On 03/31/2011 11:28 PM, Richard Henderson wrote:
>> 003 - Store dw_cfi_refs in VECs rather than linked lists. Looks
>> larger than it is due to reindentation
>
> Like 001, this one looks like it's totally independent of and of
> the other changes, and a good cleanup. Please go ahead and te
On 03/31/2011 03:07 PM, Bernd Schmidt wrote:
> No, it's used - but it looks like I forgot to quilt refresh and the
> final.c changes weren't included. New patch below. After this patch, the
> whole function is processed before final, and rather than emitting cfi
> directives immediately, we create
On 03/31/2011 11:28 PM, Richard Henderson wrote:
>> Rather than use a CFG, I've tried to do something similar to
>> compute_barrier_args_size, using JUMP_LABELs etc.
>
> A reasonable solution for now, I suppose.
Ok, sounds like you haven't discovered a fatal flaw; I'll keep hacking
on it.
>> Sum
On 03/31/2011 12:59 PM, Bernd Schmidt wrote:
>> So long as late late compilation passes continue to not move frame-related
>> insns across basic block boundaries, we should be fine.
>
> I'm nervous about this as the reorg pass can do arbitrary
> transformations. On Blackfin for example, we can reo
On 03/26/2011 04:26 AM, Richard Henderson wrote:
> I think the ideal thing would be a pass while the cfg is still extant that
> captures the unwind info into notes; these can be recorded at basic block
> boundaries, so that they persist until the end of compilation.
>
> So long as late late compil
On 03/25/2011 10:34 AM, Bernd Schmidt wrote:
> I don't know much about the unwinding code. I'm currently thinking about
> writing out a cfi_remember_state at the start of the function, restoring
> that clean state when necessary at the start of a new block and emitting
> the necessary directives to
On 03/23/2011 06:19 PM, Richard Henderson wrote:
> In general, with shrink-wrapping, we can have essentially arbitrary
> differences in unwind info between blocks that are sequential.
So, while that isn't the case just yet with the current shrink-wrapping
patch, it seems I will either have to make
On 03/23/2011 06:27 PM, Richard Henderson wrote:
> On 03/23/2011 10:22 AM, Bernd Schmidt wrote:
>> On 03/23/2011 06:19 PM, Richard Henderson wrote:
>>> body
>>> body
>>> restore r1 XXX
>>> restore r2 XXX
>>> jmp L2 XXX
>>>
>>> L1: bodyYYY
>>> b
On 03/23/2011 10:22 AM, Bernd Schmidt wrote:
> On 03/23/2011 06:19 PM, Richard Henderson wrote:
>> body
>> body
>> restore r1 XXX
>> restore r2 XXX
>> jmp L2 XXX
>>
>> L1: bodyYYY
>> bodyYYY
>> restore r2
>>
>> L2: rest
On 03/23/2011 06:19 PM, Richard Henderson wrote:
> body
> body
> restore r1 XXX
> restore r2 XXX
> jmp L2 XXX
>
> L1: bodyYYY
> bodyYYY
> restore r2
>
> L2: restore r3
> return
> In general, with shrin
On 03/23/2011 09:48 AM, Bernd Schmidt wrote:
>> With no more code than this, I cannot believe you're generating correct
>> unwind info anymore.
>
> Why not? Are you worried about the code at the destination of the jump?
> That should be preceded by another block falling through into it which
> als
On 03/23/2011 05:46 PM, Richard Henderson wrote:
> On 03/23/2011 07:50 AM, Bernd Schmidt wrote:
>> dwarf2out has code that starts scanning from NOTE_INSN_EPILOGUE_BEG
>> until it finds the return jump. When there is common code in several
>> blocks ending in a return, we might want to share this, a
On 03/23/2011 07:50 AM, Bernd Schmidt wrote:
> dwarf2out has code that starts scanning from NOTE_INSN_EPILOGUE_BEG
> until it finds the return jump. When there is common code in several
> blocks ending in a return, we might want to share this, and in that case
> it would be possible to encounter a
21 matches
Mail list logo
