[Bug middle-end/77718] [7 Regression] expand_builtin_memcmp swaps args
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77718
--- Comment #5 from Aaron Sawdey ---
On Tue, 2016-09-27 at 14:30 +, bernds at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77718
>
> --- Comment #4 from Bernd Schmidt ---
> So something like this maybe?
>
> Index: builtins.c
> ===
> --- builtins.c (revision 240511)
> +++ builtins.c (working copy)
> @@ -3707,11 +3707,13 @@ expand_builtin_memcmp (tree exp, rtx tar
>
> by_pieces_constfn constfn = NULL;
>
> - const char *src_str = c_getstr (arg1);
> - if (src_str == NULL)
> -src_str = c_getstr (arg2);
> - else
> -std::swap (arg1_rtx, arg2_rtx);
> + const char *src_str = c_getstr (arg2);
> + if (result_eq && src_str == NULL)
> +{
> + src_str = c_getstr (arg1);
> + if (src_str != NULL)
> + std::swap (arg1_rtx, arg2_rtx);
> +}
>
> /* If SRC is a string constant and block move would be done
> by pieces, we can avoid loading the string from memory
Bernd,
Yeah that is about what I was thinking it needed. I'll test this on
ppc64le.
Thanks,
Aaron
[Bug middle-end/65391] unnecessary load of conditionally updated pointer in loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65391 --- Comment #3 from Aaron Sawdey --- I tried applying the patch that Thomas posted for 64616 (https://gcc.gnu.org/ml/gcc-patches/2015-03/msg00272.html) to trunk 221350 but that did not change the generated code for this test case on powerpc64le.
[Bug middle-end/65391] unnecessary load of conditionally updated pointer in loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65391 --- Comment #2 from Aaron Sawdey --- Asm for the test case as in the description (load/store of *o_ptr for every update): compute_object_gain: ld 9,0(3) li 10,0 std 10,0(4) cmpdi 7,9,0 beqlr 7 .p2align 5,,31 .L6: cmpd 7,5,9 blt 7,.L3 ld 10,0(4) add 9,10,9 std 9,0(4) .L3: ldu 9,8(3) cmpdi 7,9,0 bne 7,.L6 blr Same test case, but with __restrict__ removed (essentially no difference): compute_object_gain: li 9,0 std 9,0(4) ld 9,0(3) cmpdi 7,9,0 beqlr 7 .p2align 5,,31 .L6: cmpd 7,5,9 blt 7,.L3 ld 10,0(4) add 9,10,9 std 9,0(4) .L3: ldu 9,8(3) cmpdi 7,9,0 bne 7,.L6 blr Remove the if() and add __restrict__ back (no load or store of *o_ptr in the loop): compute_object_gain: ld 9,0(3) li 8,0 li 10,0 std 8,0(4) cmpdi 7,9,0 beqlr 7 .p2align 4,,15 .L5: add 10,10,9 ldu 9,8(3) cmpdi 7,9,0 bne 7,.L5 std 10,0(4) blr Remove both the if() and __restrict__ (now store to *o_ptr is in the loop but no load): compute_object_gain: li 9,0 li 10,0 std 9,0(4) ld 9,0(3) cmpdi 7,9,0 beqlr 7 .p2align 5,,31 .L5: add 10,10,9 std 10,0(4) ldu 9,8(3) cmpdi 7,9,0 bne 7,.L5 blr
[Bug middle-end/65391] New: unnecessary load of conditionally updated pointer in loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65391
Bug ID: 65391
Summary: unnecessary load of conditionally updated pointer in
loop
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: acsawdey at linux dot vnet.ibm.com
CC: dje at gcc dot gnu.org, pthaugen at us dot ibm.com
When compiling for powerpc64 or powerpc64le with -O3, a load and store of
*o_ptr is done inside the loop.
If you remove the if statement and make the update unconditional, then the load
goes away and the store is deferred until after the loop.
If you remove the __restrict__ keywords, then the store remains in the loop in
either case as expected. However the load is still done in the loop if the
update is conditional.
void compute_object_gain(long * __restrict__ p_ptr, long * __restrict__ o_ptr,
long g_order)
{
long a_binding;
*o_ptr = 0;
while(*p_ptr!=0) {
a_binding = *p_ptr;
if(a_binding <= g_order)
*o_ptr += a_binding;
p_ptr++;
}
}
This behavior is consistent on 4.1, 4.5, 4.6, 4.7, 4.8, and 5.0 (trunk 220806).
[Bug ipa/64586] internal compiler error in ipa-inline.c:1664
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64586 --- Comment #5 from Aaron Sawdey --- This is also fixed by 219556.
[Bug ipa/64586] New: internal compiler error in ipa-inline.c:1664
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64586 Bug ID: 64586 Summary: internal compiler error in ipa-inline.c:1664 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: acsawdey at linux dot vnet.ibm.com CC: bergner at vnet dot ibm.com, hubicka at ucw dot cz Created attachment 34438 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34438&action=edit preprocessed test case Revision 219452 breaks ipa for this test case: g++ -std=gnu++11 -O2 -fPIC -c blackcalculator.i blackcalculator.cpp:355:1: internal compiler error: in inline_small_functions, at ipa-inline.c:1664 } ^ 0x11095fd3 inline_small_functions ../../gcc/gcc/ipa-inline.c:1664 0x11095fd3 ipa_inline ../../gcc/gcc/ipa-inline.c:2163 0x11095fd3 execute ../../gcc/gcc/ipa-inline.c:2536 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <http://gcc.gnu.org/bugs.html> for instructions. This was observed when building on/for: powerpc64le-unknown-linux-gnu 219451 does not fail. It also does not fail if you omit -fPIC.
