Bernd Schmidt writes:
> On 09/11/11 11:03, Richard Sandiford wrote:
>> Richard Sandiford writes:
>>> I think I need to play around with it a bit before I understand enough
>>> to review. I'll try to find time this weekend.
>>
>> Does the attached patch look OK? It should fix a couple of things
On 09/11/11 11:03, Richard Sandiford wrote:
> Richard Sandiford writes:
>> I think I need to play around with it a bit before I understand enough
>> to review. I'll try to find time this weekend.
>
> Does the attached patch look OK? It should fix a couple of things.
Sure!
Bernd
Richard Sandiford writes:
> I think I need to play around with it a bit before I understand enough
> to review. I'll try to find time this weekend.
Does the attached patch look OK? It should fix a couple of things.
First, on MIPS16, this code:
/* Set TARGET to BASE + STEP1. */
target = ba
Bernd Schmidt writes:
> On 09/08/11 16:08, Richard Sandiford wrote:
>> I suppose I still don't get why this is OK but this:
>>
>>> @@ -10324,12 +10350,26 @@ mips_expand_epilogue (bool sibcall_p)
>>>if (!TARGET_MIPS16)
>>> target = stack_pointer_rtx;
>>>
>>> - emit_insn (gen_add
On 09/08/11 16:08, Richard Sandiford wrote:
> I suppose I still don't get why this is OK but this:
>
>> @@ -10324,12 +10350,26 @@ mips_expand_epilogue (bool sibcall_p)
>>if (!TARGET_MIPS16)
>> target = stack_pointer_rtx;
>>
>> - emit_insn (gen_add3_insn (target, base, adjust));
Richard Henderson writes:
> On 09/08/2011 03:08 PM, Richard Sandiford wrote:
>> Bernd Schmidt writes:
>>> @@ -10227,17 +10236,30 @@ mips_expand_prologue (void)
>>> emit_insn (gen_blockage ());
>>> }
>>>
>>> -/* Emit instructions to restore register REG from slot MEM. */
>>> +/* Emit ins
On 09/08/2011 03:08 PM, Richard Sandiford wrote:
> Bernd Schmidt writes:
>> @@ -10227,17 +10236,30 @@ mips_expand_prologue (void)
>> emit_insn (gen_blockage ());
>> }
>>
>> -/* Emit instructions to restore register REG from slot MEM. */
>> +/* Emit instructions to restore register REG fr
Bernd Schmidt writes:
> On 09/08/11 16:08, Richard Sandiford wrote:
>> Also, this:
>>
>> @@ -10442,7 +10495,7 @@ mips_expand_epilogue (bool sibcall_p)
>> }
>>else
>> {
>> - unsigned int regno;
>> + rtx pat;
>>
>>/* When generating MIPS16 code, the normal
>>
On 09/08/11 16:08, Richard Sandiford wrote:
> Also, this:
>
> @@ -10442,7 +10495,7 @@ mips_expand_epilogue (bool sibcall_p)
> }
>else
> {
> - unsigned int regno;
> + rtx pat;
>
> /* When generating MIPS16 code, the normal
>mips_for_each_saved_g
Bernd Schmidt writes:
> @@ -10227,17 +10236,30 @@ mips_expand_prologue (void)
> emit_insn (gen_blockage ());
> }
>
> -/* Emit instructions to restore register REG from slot MEM. */
> +/* Emit instructions to restore register REG from slot MEM. Also update
> + the cfa_restores list. *
Bernd Schmidt writes:
> Testing with the shrink-wrapping patch added reveals a problem with the
> mips16 "save" insn: sometimes we store registers that shouldn't be
> considered saved registers; we have to clear RTX_FRAME_RELATED_P for
> these. Testing in progress with mips-elf, "ips16/arch=mips32
Testing with the shrink-wrapping patch added reveals a problem with the
mips16 "save" insn: sometimes we store registers that shouldn't be
considered saved registers; we have to clear RTX_FRAME_RELATED_P for
these. Testing in progress with mips-elf, "ips16/arch=mips32r2/abi=32"
and some other multi
On Wed, Sep 07, 2011 at 12:28:30PM +0200, Bernd Schmidt wrote:
> Question for Richard H.: What is this actually good for, other than
> presenting consistent information to dwarf2cfi? Do we actually expect
> code to unwind through the middle of an epilogue?
With -fasynchronous-unwind-tables and e.g
On Wed, 7 Sep 2011, Richard Guenther wrote:
> With async signals we can at least get interrupted in the middle of an
> epilogue. What you are allowed to do here (throw an exception?
> perform manual unwinding? use gdb which unwinds?) is another
> question. ISTR customer requests for this feature
On Wed, Sep 7, 2011 at 12:28 PM, Bernd Schmidt wrote:
> Here's a new version, which adds support for mips16 and tries to avoid
> the window with the frame pointer restore.
>
> Testing mips16 is problematic, all the execute tests fail before and
> after - I interpret one of your earlier mails to sa
Here's a new version, which adds support for mips16 and tries to avoid
the window with the frame pointer restore.
Testing mips16 is problematic, all the execute tests fail before and
after - I interpret one of your earlier mails to say that this is
expected. There are no new compilation failures w
Richard Henderson writes:
> On 09/05/2011 01:36 PM, Richard Sandiford wrote:
>> Richard Henderson writes:
>>> On 09/01/2011 12:13 AM, Richard Sandiford wrote:
Also, for the frame_pointer_required case, it looks like there's a
window between the restoration of the frame pointer and the d
On 09/05/2011 01:36 PM, Richard Sandiford wrote:
> Richard Henderson writes:
>> On 09/01/2011 12:13 AM, Richard Sandiford wrote:
>>> Also, for the frame_pointer_required case, it looks like there's a
>>> window between the restoration of the frame pointer and the deallocation
>>> of the stack in w
Richard Henderson writes:
> On 09/01/2011 12:13 AM, Richard Sandiford wrote:
>> Also, for the frame_pointer_required case, it looks like there's a
>> window between the restoration of the frame pointer and the deallocation
>> of the stack in which the CFA is still defined in terms of the frame
>>
On 09/01/2011 12:13 AM, Richard Sandiford wrote:
> Also, for the frame_pointer_required case, it looks like there's a
> window between the restoration of the frame pointer and the deallocation
> of the stack in which the CFA is still defined in terms of the frame
> pointer register. Is that signif
On 09/01/2011 03:07 AM, Bernd Schmidt wrote:
> On 08/31/11 20:43, Richard Sandiford wrote:
>> Bernd Schmidt writes:
>>> This is necessary when adding shrink-wrapping; otherwise dwarf2cfi sees
>>> inconsistent information and aborts.
>>>
>>> Tested on mips64-elf together with the rest of the shrink
Bernd Schmidt writes:
> On 09/01/11 21:19, Richard Sandiford wrote:
>> Richard Sandiford writes:
>>> Gah, my bad, sorry. I'd forgotten mipsisa32-elf is EABI32
>>> rather than o32. mips-elf with -mips32/-mips16 would test
>>> what I was after.
>>
>> Sigh. Obviously not my day. I just remember
On 09/01/11 21:19, Richard Sandiford wrote:
> Richard Sandiford writes:
>> Gah, my bad, sorry. I'd forgotten mipsisa32-elf is EABI32
>> rather than o32. mips-elf with -mips32/-mips16 would test
>> what I was after.
>
> Sigh. Obviously not my day. I just remembered that the default
> mips-elf
Richard Sandiford writes:
> Gah, my bad, sorry. I'd forgotten mipsisa32-elf is EABI32
> rather than o32. mips-elf with -mips32/-mips16 would test
> what I was after.
Sigh. Obviously not my day. I just remembered that the default
mips-elf simulator won't accept -mips32 instructions, so you nee
Bernd Schmidt writes:
> On 08/31/11 20:43, Richard Sandiford wrote:
>> Bernd Schmidt writes:
>>> This is necessary when adding shrink-wrapping; otherwise dwarf2cfi sees
>>> inconsistent information and aborts.
>>>
>>> Tested on mips64-elf together with the rest of the shrink-wrapping
>>> patches.
On 08/31/11 20:43, Richard Sandiford wrote:
> Bernd Schmidt writes:
>> This is necessary when adding shrink-wrapping; otherwise dwarf2cfi sees
>> inconsistent information and aborts.
>>
>> Tested on mips64-elf together with the rest of the shrink-wrapping
>> patches. Ok?
>
> It looks like the cur
Bernd Schmidt writes:
> On 08/31/11 20:43, Richard Sandiford wrote:
>> Bernd Schmidt writes:
>>> This is necessary when adding shrink-wrapping; otherwise dwarf2cfi sees
>>> inconsistent information and aborts.
>>>
>>> Tested on mips64-elf together with the rest of the shrink-wrapping
>>> patches.
On 08/31/11 20:43, Richard Sandiford wrote:
> Bernd Schmidt writes:
>> This is necessary when adding shrink-wrapping; otherwise dwarf2cfi sees
>> inconsistent information and aborts.
>>
>> Tested on mips64-elf together with the rest of the shrink-wrapping
>> patches. Ok?
>
> It looks like the cur
Bernd Schmidt writes:
> This is necessary when adding shrink-wrapping; otherwise dwarf2cfi sees
> inconsistent information and aborts.
>
> Tested on mips64-elf together with the rest of the shrink-wrapping
> patches. Ok?
It looks like the current code doesn't handle the RESTORE instruction.
Could
This is necessary when adding shrink-wrapping; otherwise dwarf2cfi sees
inconsistent information and aborts.
Tested on mips64-elf together with the rest of the shrink-wrapping
patches. Ok?
Bernd
* config/mips/mips.c (cfa_restores): New static variable.
(mips_restore_reg): Add to
30 matches
Mail list logo
