On Wed, Aug 03, 2016 at 04:08:30PM -0600, Jeff Law wrote:
> On 08/03/2016 11:41 AM, Bernd Edlinger wrote:
> >On 08/03/16 17:38, Jeff Law wrote:
> >>cse.c changes look good, but I'd really like to see a testcase for each
> >>issue in the dejagnu framework. Extra points if you tried to build a
> >>u
On 08/03/2016 11:41 AM, Bernd Edlinger wrote:
On 08/03/16 17:38, Jeff Law wrote:
cse.c changes look good, but I'd really like to see a testcase for each
issue in the dejagnu framework. Extra points if you tried to build a
unit test using David M's framework, but that isn't required.
The testca
On 08/03/16 17:38, Jeff Law wrote:
> cse.c changes look good, but I'd really like to see a testcase for each
> issue in the dejagnu framework. Extra points if you tried to build a
> unit test using David M's framework, but that isn't required.
>
> The testcase from 70903 ought to be trivial to add
On 08/01/2016 12:52 PM, Bernd Edlinger wrote:
Hi Jeff,
On 08/01/16 19:54, Jeff Law wrote:
> Looks like you've probably nailed it. It'll be interesting see if
> there's any fallout (though our RTL optimizer testing is pretty weak, so
> even if there were, I doubt we'd catch it).
>
If there is,
On 08/02/2016 02:16 PM, Bernd Schmidt wrote:
On 08/02/2016 06:46 PM, Segher Boessenkool wrote:
On Tue, Aug 02, 2016 at 09:21:34AM -0600, Jeff Law wrote:
However I think there are more paradoxical subregs generated all over,
but the aarch64 insv code pattern did trigger more hidden bugs than
any
Hi,
Is it OK for the trunk?
I guess so, but need an explicit OK.
Thanks
Bernd.
On 08/01/16 20:52, Bernd Edlinger wrote:
> Hi Jeff,
>
> On 08/01/16 19:54, Jeff Law wrote:
>> Looks like you've probably nailed it. It'll be interesting see if
>> there's any fallout (though our RTL optimizer testi
On 08/02/2016 06:46 PM, Segher Boessenkool wrote:
On Tue, Aug 02, 2016 at 09:21:34AM -0600, Jeff Law wrote:
However I think there are more paradoxical subregs generated all over,
but the aarch64 insv code pattern did trigger more hidden bugs than
any other port. It is certainly unfortunate that
On 08/02/2016 11:46 AM, Richard Biener wrote:
But we love to exploit undefined behavior elsewhere, too. Now the
init-regs pass comes to my mind again (papering over issues
elsewhere)..
True. I just haven't seen that the don't care bits created by
paradoxical subregs has actually been all that
On August 2, 2016 5:21:34 PM GMT+02:00, Jeff Law wrote:
>On 08/01/2016 05:31 PM, Segher Boessenkool wrote:
>> Hi,
>>
>> On Mon, Aug 01, 2016 at 06:52:54PM +, Bernd Edlinger wrote:
>>> On 08/01/16 19:54, Jeff Law wrote:
Looks like you've probably nailed it. It'll be interesting see if
>>>
On Tue, Aug 02, 2016 at 09:21:34AM -0600, Jeff Law wrote:
> >>However I think there are more paradoxical subregs generated all over,
> >>but the aarch64 insv code pattern did trigger more hidden bugs than
> >>any other port. It is certainly unfortunate that the major source
> >>of paradoxical subr
On 08/01/2016 05:31 PM, Segher Boessenkool wrote:
Hi,
On Mon, Aug 01, 2016 at 06:52:54PM +, Bernd Edlinger wrote:
On 08/01/16 19:54, Jeff Law wrote:
Looks like you've probably nailed it. It'll be interesting see if
there's any fallout (though our RTL optimizer testing is pretty weak, so
e
Hi,
On Mon, Aug 01, 2016 at 06:52:54PM +, Bernd Edlinger wrote:
> On 08/01/16 19:54, Jeff Law wrote:
> > Looks like you've probably nailed it. It'll be interesting see if
> > there's any fallout (though our RTL optimizer testing is pretty weak, so
> > even if there were, I doubt we'd catch it
Hi Jeff,
On 08/01/16 19:54, Jeff Law wrote:
> Looks like you've probably nailed it. It'll be interesting see if
> there's any fallout (though our RTL optimizer testing is pretty weak, so
> even if there were, I doubt we'd catch it).
>
If there is, it will probably a performance regression...
An
On 07/31/2016 04:44 AM, Bernd Edlinger wrote:
like this?
Index: emit-rtl.c
===
--- emit-rtl.c (revision 238891)
+++ emit-rtl.c (working copy)
@@ -1156,7 +1156,11 @@
{
#if defined(POINTERS_EXTEND_UNSIGNED)
if (((GE
On 07/30/2016 02:17 AM, Bernd Edlinger wrote:
In your first mail you showed reg 481 as _not_ being REG_POINTER:
(insn 1047 1046 1048 (set (reg:DI 481)
(subreg:DI (reg/f:SI 479) 0)) y.c:12702 -1
(nil))
(note the lack of /f). So which is it? REG_POINTER here is not correct
as fa
On 07/31/16 12:43, Bernd Edlinger wrote:
> I found out that the trouble starts one instruction earlier:
>
> (insn 19 40 20 2 (set (subreg:DI (reg:QI 93) 0)
> ) pr.c:8 50 {*movdi_aarch64}
> (expr_list:REG_DEAD (reg:DI 110 [ D.3037 ])
> (nil)))
>
oops, my e-mail missed one li
On 07/30/16 13:39, Segher Boessenkool wrote:
> On Sat, Jul 30, 2016 at 08:17:59AM +, Bernd Edlinger wrote:
>> Ok, I the incorrect REG_POINTER is done here:
>>
>> cse_main -> reg_scan -> reg_scan_mark_refs -> set_reg_attrs_from_value
>>
>> and here I see a bug, because if POINTERS_EXTEND_UNSIGNE
On Sat, Jul 30, 2016 at 08:17:59AM +, Bernd Edlinger wrote:
> Ok, I the incorrect REG_POINTER is done here:
>
> cse_main -> reg_scan -> reg_scan_mark_refs -> set_reg_attrs_from_value
>
> and here I see a bug, because if POINTERS_EXTEND_UNSIGNED
> can_be_reg_pointer is only set to false if x i
On 07/29/16 15:03, Bernd Edlinger wrote:
> On 07/29/16 09:02, Segher Boessenkool wrote:
>> On Thu, Jul 28, 2016 at 08:59:44PM +, Bernd Edlinger wrote:
>>> (insn 1047 1044 1048 101 (set (reg/f:DI 481)
>>> (subreg:DI (reg/f:SI 545) 0)) isl_input.c:2496 50
>>> {*movdi_aarch64}
>>>
On 07/29/16 09:02, Segher Boessenkool wrote:
> On Thu, Jul 28, 2016 at 08:59:44PM +, Bernd Edlinger wrote:
>> (insn 1047 1044 1048 101 (set (reg/f:DI 481)
>> (subreg:DI (reg/f:SI 545) 0)) isl_input.c:2496 50 {*movdi_aarch64}
>>(nil))
>
> In your first mail you showed reg 481 a
On Thu, Jul 28, 2016 at 08:59:44PM +, Bernd Edlinger wrote:
> (insn 1047 1044 1048 101 (set (reg/f:DI 481)
> (subreg:DI (reg/f:SI 545) 0)) isl_input.c:2496 50 {*movdi_aarch64}
> (nil))
In your first mail you showed reg 481 as _not_ being REG_POINTER:
(insn 1047 1046 1048 (set (
Hi,
On 07/27/16 23:31, Jeff Law wrote:
> So you're stumbling into another really interesting area.
>
Absolutely, I am just too curious what's going on here ;-)
> I can hazard a guess that the reason we create the paradoxical SUBREG
> rather than a zero or sign extension is because various optim
Am 27.07.2016 um 23:31 schrieb Jeff Law:
> On 07/26/2016 11:32 AM, Bernd Edlinger wrote:
>> Hi!
>>
>> As described in PR 71779 and PR 70903 we have a wrong code issue on
>> aarch64
>> which is triggered by a paradoxical subreg that can be created in
>> store_bit_field_using_insv when the target has
On 07/26/2016 11:32 AM, Bernd Edlinger wrote:
Hi!
As described in PR 71779 and PR 70903 we have a wrong code issue on aarch64
which is triggered by a paradoxical subreg that can be created in
store_bit_field_using_insv when the target has an EP_insv bitfield instruction.
The attached patch chan
Hi!
As described in PR 71779 and PR 70903 we have a wrong code issue on aarch64
which is triggered by a paradoxical subreg that can be created in
store_bit_field_using_insv when the target has an EP_insv bitfield instruction.
The attached patch changes this insn...
(insn 1047 1046 1048 (set (reg
25 matches
Mail list logo
