https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287
--- Comment #38 from luoxhu at gcc dot gnu.org ---
Author: luoxhu
Date: Wed Aug 14 02:18:33 2019
New Revision: 274411
URL: https://gcc.gnu.org/viewcvs?rev=274411=gcc=rev
Log:
Enable math functions linking with static library for LTO
In LTO mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287
--- Comment #39 from luoxhu at gcc dot gnu.org ---
Author: luoxhu
Date: Mon Aug 26 08:53:27 2019
New Revision: 274921
URL: https://gcc.gnu.org/viewcvs?rev=274921=gcc=rev
Log:
Backport r274411 from trunk to gcc-9-branch
Backport r274411
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92398
--- Comment #10 from luoxhu at gcc dot gnu.org ---
Author: luoxhu
Revision: 278890
Modified property: svn:log
Modified: svn:log at Wed Dec 4 08:50:33 2019
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94036
luoxhu at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93582
luoxhu at gcc dot gnu.org changed:
What|Removed |Added
CC||luoxhu at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71509
luoxhu at gcc dot gnu.org changed:
What|Removed |Added
CC||linkw at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92599
luoxhu at gcc dot gnu.org changed:
What|Removed |Added
CC||luoxhu at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71509
luoxhu at gcc dot gnu.org changed:
What|Removed |Added
CC||luoxhu at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69678
luoxhu at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93189
--- Comment #3 from luoxhu at gcc dot gnu.org ---
Author: luoxhu
Revision: 279986
Modified property: svn:log
Modified: svn:log at Wed Jan 8 01:32:45 2020
--
--- svn:log
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94036
luoxhu at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61837
--- Comment #9 from luoxhu at gcc dot gnu.org ---
(In reply to Segher Boessenkool from comment #8)
> -funswitch-loops changes things like
>
> for (...) {
> if (...)
> ...1;
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61837
--- Comment #7 from luoxhu at gcc dot gnu.org ---
(In reply to Segher Boessenkool from comment #6)
> But -funswitch-loops is much stronger than we want here, and the wrong
> thing to use at -O2 (it often generates *slower* code!)
Not sur
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61837
--- Comment #5 from luoxhu at gcc dot gnu.org ---
"-O2 -funswitch-loops" could generate expected code for s<=0, unswitch-loops is
enabled by -O3, so this issue is reduced to duplicate of PR67288?
foo:
.LFB0:
.cfi_startproc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61837
luoxhu at gcc dot gnu.org changed:
What|Removed |Added
CC||luoxhu at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91518
luoxhu at gcc dot gnu.org changed:
What|Removed |Added
CC||luoxhu at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83403
luoxhu at gcc dot gnu.org changed:
What|Removed |Added
CC||luoxhu at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 91518, which changed state.
Bug 91518 Summary: [9 Regression] segfault when run CPU2006 465.tonto since
r263875
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91518
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91518
luoxhu at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83403
luoxhu at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
Bug 53947 depends on bug 83403, which changed state.
Bug 83403 Summary: Missed register promotion opportunities in loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83403
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37451
--- Comment #11 from luoxhu at gcc dot gnu.org ---
fixed on master.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37451
luoxhu at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88842
luoxhu at gcc dot gnu.org changed:
What|Removed |Added
CC||luoxhu at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30271
luoxhu at gcc dot gnu.org changed:
What|Removed |Added
CC||luoxhu at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69493
luoxhu at gcc dot gnu.org changed:
What|Removed |Added
CC||luoxhu at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70053
luoxhu at gcc dot gnu.org changed:
What|Removed |Added
CC||bergner at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70053
--- Comment #6 from luoxhu at gcc dot gnu.org ---
"-O2 -ftree-slp-vectorize" could also generate the expected simple fmrs.
Reason is pass_cselim will transform conditional stores into unconditional ones
with PHI instructions when vec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70053
luoxhu at gcc dot gnu.org changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69493
--- Comment #10 from luoxhu at gcc dot gnu.org ---
In expand, Power8 will emit two register permute instructions to byte swap the
contents by rs6000_emit_le_vsx_move.
P9:
5: NOTE_INSN_BASIC_BLOCK 2
2: r129:TF=%1:TF
3: r130:TF=%3:TF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70053
--- Comment #9 from luoxhu at gcc dot gnu.org ---
(In reply to Segher Boessenkool from comment #8)
> I see no conversion there?
>
> But, why does it it store to memory at all?
Yes, no conversion for this case, only adjust_address to TI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89310
luoxhu at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71309
luoxhu at gcc dot gnu.org changed:
What|Removed |Added
CC||luoxhu at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89310
luoxhu at gcc dot gnu.org changed:
What|Removed |Added
CC||luoxhu at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89310
--- Comment #5 from luoxhu at gcc dot gnu.org ---
Thanks. I copied the code from movsf_from_si to make a define_insn_and_split
for "movsf_from_si2", but we don't have define_insn for rldicr, so I use
gen_anddi3 instead, any comment?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96343
--- Comment #4 from luoxhu at gcc dot gnu.org ---
I tried to build both ADIOS2 and WarpX(with INTERPROCEDURAL_OPTIMIZATION) on a
Power8 machine with gcc 9.3.0&9.2.1, no LTO error seen.
/usr/bin/cmake ../ -DCMAKE_C_COMPILER=/opt/at12.0/bin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79251
luoxhu at gcc dot gnu.org changed:
What|Removed |Added
CC||luoxhu at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22326
--- Comment #14 from luoxhu at gcc dot gnu.org ---
(In reply to luoxhu from comment #13)
>
> 2) mad2.c
>
> float foo (double x, float y, float z)
> {
>return ( y * fabs (x) + z );
> }
>
>
> mad2.c.098
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22326
--- Comment #13 from luoxhu at gcc dot gnu.org ---
Tried implementation with backprop, found that this model seems not suitable
for double promotion remove with BACK propagation. i.e:
1) mad1.c
float foo (float x, float y, float z
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22326
--- Comment #17 from luoxhu at gcc dot gnu.org ---
(In reply to rsand...@gcc.gnu.org from comment #16)
> > 2) mad2.c
> >
> > float foo (double x, float y, float z)
> > {
> >return ( y * fabs (x) + z
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98093
luoxhu at gcc dot gnu.org changed:
What|Removed |Added
CC||luoxhu at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98093
--- Comment #2 from luoxhu at gcc dot gnu.org ---
https://gcc.gnu.org/pipermail/gcc-patches/2020-October/555907.html
[PATCH 3/4] rs6000: Enable vec_insert for P8 with
rs6000_expand_vector_set_var_p8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98066
--- Comment #8 from luoxhu at gcc dot gnu.org ---
Thanks for the quick fix!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22326
luoxhu at gcc dot gnu.org changed:
What|Removed |Added
CC||luoxhu at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22326
--- Comment #5 from luoxhu at gcc dot gnu.org ---
With above hack, changing argument x from float to double could still generate
correct code with conversion of fabsf result:
float foo(float f, double x, float y) {
return (fabs(f)*x+y
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22326
--- Comment #10 from luoxhu at gcc dot gnu.org ---
Even we could optimize fabs to fabsf, it doesn't help here as y and z are
already promoted to double, then we still need a large pattern to match the
MUL expression in match.pd, so fabs to fabsf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22326
--- Comment #9 from luoxhu at gcc dot gnu.org ---
(In reply to Andrew Pinski from comment #6)
> (In reply to luoxhu from comment #4)
> > float foo(float f, float x, float y) {
> > return (fabs(f)*x+y);
> > }
> >
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98827
--- Comment #1 from luoxhu at gcc dot gnu.org ---
Strange that I see only xxpermdi fail, should be 4 instead of 12. rldic passes
for m64, what's your configuration please?
=== gcc tests ===
Schedule of variations:
unix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98065
--- Comment #4 from luoxhu at gcc dot gnu.org ---
Sorry, my patch
https://gcc.gnu.org/pipermail/gcc-patches/2020-October/555906.html
could fix this, but below two of them is still pending for approval, I pinged
it 5 times since last Oct. @Segher
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98799
luoxhu at gcc dot gnu.org changed:
What|Removed |Added
CC||luoxhu at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22326
--- Comment #22 from luoxhu at gcc dot gnu.org ---
https://gcc.gnu.org/pipermail/gcc/2020-December/234474.html
So this issue seems invalid since "fabs(x)*y+z” or "fabs(x)+y+z"(x,y,z are
float) could result in -+Inf sometimes,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98093
luoxhu at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98958
luoxhu at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98914
--- Comment #4 from luoxhu at gcc dot gnu.org ---
*** Bug 98958 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79251
luoxhu at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98799
luoxhu at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98065
Bug 98065 depends on bug 98799, which changed state.
Bug 98799 Summary: [11 Regression] vector_set_var ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98799
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98827
--- Comment #3 from luoxhu at gcc dot gnu.org ---
I know it now, the r11-6858 did some changes the P8 code generation, so the
latest failure also changes.
https://gcc.gnu.org/pipermail/gcc-testresults/2021-January/651154.html
current failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98914
--- Comment #1 from luoxhu at gcc dot gnu.org ---
The type of k in the case should be "long" to reproduce the issue,
ICE happens at
rs6000_expand_vector_set: gcc_assert (GET_MODE (idx) == E_SImode);
Reason is the vector index var
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93571
luoxhu at gcc dot gnu.org changed:
What|Removed |Added
CC||luoxhu at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100866
--- Comment #5 from luoxhu at gcc dot gnu.org ---
(In reply to Segher Boessenkool from comment #4)
> This PR is specifically about the vec_revb builtin. But yes, we should
> look at what is generated for all other code (having only the b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93571
--- Comment #3 from luoxhu at gcc dot gnu.org ---
BTW, I didn't see performance difference between fmr and xxlor within a small
benchmark.
Max Ops Per CycleLatency (Min) Latency (Max)
fmr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101020
luoxhu at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100085
--- Comment #10 from luoxhu at gcc dot gnu.org ---
float128 to vector __int128 is fixed by:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=f700e4b0ee3ef53b48975cf89be26b9177e3a3f3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101020
luoxhu at gcc dot gnu.org changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100866
--- Comment #6 from luoxhu at gcc dot gnu.org ---
For V4SI, it is also better to use vector splat and vector rotate operations.
revb:
.LFB0:
.cfi_startproc
vspltish %v1,8
vspltisw %v0,-16
vrlh %v2,%v2,%v1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100866
--- Comment #8 from luoxhu at gcc dot gnu.org ---
(In reply to Jens Seifert from comment #7)
> Regarding vec_revb for vector unsigned int. I agree that
> revb:
> .LFB0:
> .cfi_startproc
> vspltish %v1,8
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100866
--- Comment #13 from luoxhu at gcc dot gnu.org ---
It is not visible in combine due to the constant data is in *.LC0 and
UNSPEC_VPERM. Will shelf this and switch to other high priority issues.
pr100866.c.277r.combine:
(note 4 0 20 2 [bb 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100866
--- Comment #3 from luoxhu at gcc dot gnu.org ---
diff --git a/gcc/config/rs6000/altivec.md b/gcc/config/rs6000/altivec.md
index 097a127be07..35b3f1a0e1a 100644
--- a/gcc/config/rs6000/altivec.md
+++ b/gcc/config/rs6000/altivec.md
@@ -1932,7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100866
luoxhu at gcc dot gnu.org changed:
What|Removed |Added
CC||luoxhu at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100085
--- Comment #9 from luoxhu at gcc dot gnu.org ---
Patch sent, it could fix the __float128 to vector __int128 issue,
https://gcc.gnu.org/pipermail/gcc-patches/2021-June/571689.html
But for __float128 to __int128 mentioned in #c4, need hack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100085
luoxhu at gcc dot gnu.org changed:
What|Removed |Added
CC||luoxhu at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94613
luoxhu at gcc dot gnu.org changed:
What|Removed |Added
CC||luoxhu at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97142
--- Comment #12 from luoxhu at gcc dot gnu.org ---
Patch submitted:
https://gcc.gnu.org/pipermail/gcc-patches/2021-April/568143.html
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: luoxhu at gcc dot gnu.org
Target Milestone: ---
Test case:
unsigned int foo (unsigned char *ip, unsigned char *ref, unsigned int maxlen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101250
--- Comment #1 from luoxhu at gcc dot gnu.org ---
Patch posted:
[PATCH] ivopts: Don't adjust IV update statement if both operands use the IV in
COND [PR101250]
https://gcc.gnu.org/pipermail/gcc-patches/2021-June/573894.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90323
--- Comment #17 from luoxhu at gcc dot gnu.org ---
If the constant limitation is removed, it could be combined successfully with
my new patch for PR94613.
https://gcc.gnu.org/pipermail/gcc-patches/2021-April/569255.html
And what do you mean
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90323
--- Comment #16 from luoxhu at gcc dot gnu.org ---
> +2016-11-09 Segher Boessenkool
> +
> + * simplify-rtx.c (simplify_binary_operation_1): Simplify
> + (xor (and (xor A B) C) B) to (ior (and A C) (and B ~C)) and
&g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99718
--- Comment #4 from luoxhu at gcc dot gnu.org ---
Thanks, Jakub. It tested pass on both m32/m64, is this a reasonable fix?
@segher, will make it a patch if so.
git diff
diff --git a/gcc/config/rs6000/predicates.md b/gcc/config/rs6000
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97329
luoxhu at gcc dot gnu.org changed:
What|Removed |Added
CC||luoxhu at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99718
luoxhu at gcc dot gnu.org changed:
What|Removed |Added
CC||dje.gcc at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99718
--- Comment #15 from luoxhu at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #14)
> You still have:
> if (VECTOR_MEM_VSX_P (mode))
> {
> if (!CONST_INT_P (elt_rtx))
> {
> if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99718
--- Comment #19 from luoxhu at gcc dot gnu.org ---
https://gcc.gnu.org/pipermail/gcc-patches/2021-March/567395.html
This patch extends variable vec_insert to all 32bit VSX targets including
Power7{BE} {32,64}, Power8{BE}{32, 64}, Power8{LE}{64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99718
--- Comment #13 from luoxhu at gcc dot gnu.org ---
Performance data in #c11 is for int variable vec_insert of 32bit mode, the
float variable vec_insert of 32-bit is a bit slower but much better than
original(extra stfs+lwz of insn #17 and insn 18
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99718
--- Comment #11 from luoxhu at gcc dot gnu.org ---
Created attachment 50474
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50474=edit
32bit variable vec_insert
LLVM also generates store-hit-load instruction:
addi 3, 1,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99718
--- Comment #12 from luoxhu at gcc dot gnu.org ---
Not sure whether TARGET_DIRECT_MOVE_64BIT is the right MACRO to correctly
differentiate m32 and m64?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99718
luoxhu at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97329
luoxhu at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98914
luoxhu at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90323
--- Comment #11 from luoxhu at gcc dot gnu.org ---
I noticed that you added the below optimization with commit
a62436c0a505155fc8becac07a8c0abe2c265bfe. But it doesn't even handle this case,
cse1 pass will call simplify_binary_operation_1, both
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90323
--- Comment #12 from luoxhu at gcc dot gnu.org ---
That code was called by combine pass but fail to match.
pr newpat
(set (reg:DI 125 [ l ])
(xor:DI (and:DI (xor:DI (reg/v:DI 120 [ l ])
(reg:DI 127))
(const_int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90323
--- Comment #9 from luoxhu at gcc dot gnu.org ---
Then we could optimized it in match.pd
diff --git a/gcc/match.pd b/gcc/match.pd
index 036f92fa959..8944312c153 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -3711,6 +3711,17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90323
luoxhu at gcc dot gnu.org changed:
What|Removed |Added
CC||luoxhu at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97142
--- Comment #10 from luoxhu at gcc dot gnu.org ---
If not built with fast-math, gimple_has_side_effects will return true and cause
the expand_call_stmt fail to expand the "_1 = fmod (x_2(D), y_3(D));" to
internal function. X86 also pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90323
--- Comment #15 from luoxhu at gcc dot gnu.org ---
(In reply to Segher Boessenkool from comment #14)
> (In reply to luoxhu from comment #12)
> > That code was called by combine pass but fail to match.
>
> >
> > pr new
: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: luoxhu at gcc dot gnu.org
Target Milestone: ---
ALWAYS_EXECUTED_IN is not computed completely for nested loops. Current design
will exit if an inner loop doesn't dominate outer loop's latch or exit after
exiting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97142
luoxhu at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102178
--- Comment #2 from luoxhu at gcc dot gnu.org ---
Verified 470.lbm doesn't show regression on Power8 with Ofast.
runtime is 141 sec for r12-897, without that patch it is 142 sec.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102008
--- Comment #3 from luoxhu at gcc dot gnu.org ---
phiopt4 and sink2 are doing reverse optimizations:
pr102008.c.200t.phiopt4:
Hoisting adjacent loads from 3 and 4 into 2: _6 = foo_4(D)->a; _5 =
foo_4(D)->b;
pr102008.c.202t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102008
--- Comment #2 from luoxhu at gcc dot gnu.org ---
Confirmed if move the sink2 pass before phiopt4 could restore the previous
instructons for this case:
test:
.LFB0:
.cfi_startproc
cmp w0, 1
ldp w0, w1, [x1
1 - 100 of 166 matches
Mail list logo
