On 08/05/2011 10:41 AM, Bernd Schmidt wrote:
> PR rtl-optimization/49900
> * sched-ebb.c (add_deps_for_risky_insns): Also add dependencies to
> ensure basic blocks stay in the same order.
Ok.
r~
On 07/22/11 19:23, Bernd Schmidt wrote:
> On 07/22/11 19:17, Richard Henderson wrote:
>> On 07/22/2011 10:00 AM, Eric Botcazou wrote:
It's getting confused about loads/stores being control_flow_insns and
getting scheduled past each other nonetheless. Mind testing the following?
>>>
>>> s/
On 07/22/11 19:17, Richard Henderson wrote:
> On 07/22/2011 10:00 AM, Eric Botcazou wrote:
>>> It's getting confused about loads/stores being control_flow_insns and
>>> getting scheduled past each other nonetheless. Mind testing the following?
>>
>> s/flag_non_call_exceptions/cfun->can_throw_non_ca
On 07/22/2011 10:00 AM, Eric Botcazou wrote:
>> It's getting confused about loads/stores being control_flow_insns and
>> getting scheduled past each other nonetheless. Mind testing the following?
>
> s/flag_non_call_exceptions/cfun->can_throw_non_call_exceptions/
>
Why test either, since control
> It's getting confused about loads/stores being control_flow_insns and
> getting scheduled past each other nonetheless. Mind testing the following?
s/flag_non_call_exceptions/cfun->can_throw_non_call_exceptions/
--
Eric Botcazou
On 07/19/11 14:25, Andreas Schwab wrote:
> I'm now seeing this ICE:
>
> /bin/sh ./libtool --tag=GCJ --mode=compile
> /usr/local/gcc/gcc-20110719/Build/./gcc/gcj
> -B/usr/local/gcc/gcc-20110719/Build/ia64-suse-linux/libjava/
> -B/usr/local/gcc/gcc-20110719/Build/./gcc/ -B/usr/ia64-suse-linux/b
Bernd Schmidt writes:
> I'm not even getting to that point. ia64 has been pretty broken for me
> over the last couple of weeks.
>
> checking for exception model to use... configure: error: unable to
> detect exception model
> make: *** [configure-target-libstdc++-v3] Error 1
Did you look at conf
On 07/19/11 14:25, Andreas Schwab wrote:
> I'm now seeing this ICE:
>
> /bin/sh ./libtool --tag=GCJ --mode=compile
> /usr/local/gcc/gcc-20110719/Build/./gcc/gcj
> -B/usr/local/gcc/gcc-20110719/Build/ia64-suse-linux/libjava/
> -B/usr/local/gcc/gcc-20110719/Build/./gcc/ -B/usr/ia64-suse-linux/b
I'm now seeing this ICE:
/bin/sh ./libtool --tag=GCJ --mode=compile
/usr/local/gcc/gcc-20110719/Build/./gcc/gcj
-B/usr/local/gcc/gcc-20110719/Build/ia64-suse-linux/libjava/
-B/usr/local/gcc/gcc-20110719/Build/./gcc/ -B/usr/ia64-suse-linux/bin/
-B/usr/ia64-suse-linux/lib/ -isystem /usr/ia64-s
On 07/14/2011 09:43 AM, Bernd Schmidt wrote:
> (Although now I wonder if we could instead use one of the speculative
> load instructions? There's one that sets the NaT bit if the load would
> fault, isn't there? It's been so long I can't remember.)
We could, but we also have to insert a check load
On 07/14/11 18:39, Richard Henderson wrote:
> On 07/14/2011 09:19 AM, Bernd Schmidt wrote:
>> Yes, but not using the fixed got pointer in r1, but a random other
>> register which can have different values in the function.
>
> Oh, I think I see.
>
> So if this really had been a PLUS, as implied by
On 07/14/2011 09:19 AM, Bernd Schmidt wrote:
> Yes, but not using the fixed got pointer in r1, but a random other
> register which can have different values in the function.
Oh, I think I see.
So if this really had been a PLUS, as implied by the LO_SUM,
we would have had garbage input, produced g
On 07/14/11 18:29, Richard Henderson wrote:
> On 07/14/2011 09:23 AM, Bernd Schmidt wrote:
>> Ok, with gen_const_mem hacked into gcc-3.3 (minus setting MEM_READONLY_P
>> which doesn't exist in that tree) the load stays behind the branch where
>> it should be.
>>
>
> RTX_UNCHANGING_P was the bit ba
On 07/14/2011 09:23 AM, Bernd Schmidt wrote:
> Ok, with gen_const_mem hacked into gcc-3.3 (minus setting MEM_READONLY_P
> which doesn't exist in that tree) the load stays behind the branch where
> it should be.
>
RTX_UNCHANGING_P was the bit back then, I believe.
r~
On 07/14/11 18:19, Bernd Schmidt wrote:
> On 07/14/11 18:03, Richard Henderson wrote:
>> On 07/14/2011 03:03 AM, Bernd Schmidt wrote:
>>> +++ gcc/config/ia64/ia64.c (working copy)
>>> @@ -1047,7 +1047,7 @@
>>>tmp = gen_rtx_PLUS (Pmode, tmp, pic_offset_table_rtx);
>>>emit_insn (gen_
On 07/14/11 18:03, Richard Henderson wrote:
> On 07/14/2011 03:03 AM, Bernd Schmidt wrote:
>> +++ gcc/config/ia64/ia64.c (working copy)
>> @@ -1047,7 +1047,7 @@
>>tmp = gen_rtx_PLUS (Pmode, tmp, pic_offset_table_rtx);
>>emit_insn (gen_rtx_SET (VOIDmode, dest, tmp));
>>
>> -
On 07/14/2011 03:03 AM, Bernd Schmidt wrote:
> +++ gcc/config/ia64/ia64.c(working copy)
> @@ -1047,7 +1047,7 @@
>tmp = gen_rtx_PLUS (Pmode, tmp, pic_offset_table_rtx);
>emit_insn (gen_rtx_SET (VOIDmode, dest, tmp));
>
> - tmp = gen_rtx_LO_SUM (Pmode, dest, src);
> +
> ??? Original code:
>
>basic_block b = BLOCK_FOR_INSN (insn);
> edge e;
> for (e = b->succ; e; e = e->succ_next)
> ! if ((e->flags & EDGE_FALLTHRU) == 0)
> ! {
> ! bitmap_operation (set, set, e->dest->global_live_at_start,
> ! BITMAP_IOR);
> !
> Any particular bits you still see that don't get reverted with this patch?
The ebb_compute_jump_reg_dependencies changes. The original patch has:
* sched-ebb.c (compute_jump_reg_dependencies): New prototype.
Mark registers live on entry of the fallthrough block and conditionall
On 07/14/11 14:18, Eric Botcazou wrote:
>> Any particular bits you still see that don't get reverted with this patch?
>
> The ebb_compute_jump_reg_dependencies changes. The original patch has:
>
> * sched-ebb.c (compute_jump_reg_dependencies): New prototype.
> Mark registers live on
On 07/14/11 13:57, Eric Botcazou wrote:
>> The real problem here is that the ia64 backend lies to the rest of the
>> compiler; it produces a load instruction without showing a MEM anywhere
>> in the instruction pattern. Hence, the following patch, which reverts
>> the bogus scheduler changes and ad
> The real problem here is that the ia64 backend lies to the rest of the
> compiler; it produces a load instruction without showing a MEM anywhere
> in the instruction pattern. Hence, the following patch, which reverts
> the bogus scheduler changes and adds a MEM to a pattern in ia64.md.
This is p
On 07/14/11 13:20, Andrey Belevantsev wrote:
> Hello Bernd,
>
> FWIW, we have discussed your change with Alexander and we think you are
> right about the scheduler changes. One question is:
>
> On 14.07.2011 14:03, Bernd Schmidt wrote:
>> --- gcc/sched-deps.c(revision 176195)
>> +++ gcc/sche
Hello Bernd,
FWIW, we have discussed your change with Alexander and we think you are
right about the scheduler changes. One question is:
On 14.07.2011 14:03, Bernd Schmidt wrote:
--- gcc/sched-deps.c(revision 176195)
+++ gcc/sched-deps.c(working copy)
@@ -568,7 +568,7 @@
(r
PR11320 was a scheduler problem where an instruction was moved backwards
across a branch, leading to
addl r14 = @ltoffx(.LC2), r1
;;
(p7) addl r14 = 1, r0 <--- r14 clobbered
;;
(p7) st4 [r15] = r14
ld8.mov r14 = [r14], .LC2 <--- crash
25 matches
Mail list logo
