https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102131
--- Comment #4 from bin cheng ---
(In reply to Jiu Fu Guo from comment #3)
> The issue may come from 'iv0 cmp iv1' transform:
>
>if (c -->if (c>=b) in-loop
> -->if (b<=c) in-loop
>
> c: {4, +, 3}
> b: {1, +, 1}
>
> if ({1, +, 1} <=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101145
--- Comment #7 from bin cheng ---
(In reply to Jiu Fu Guo from comment #5)
> (In reply to bin cheng from comment #4)
> > (In reply to Jiu Fu Guo from comment #3)
> > > Yes, while the code in adjust_cond_for_loop_until_wrap seems somehow
> > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101145
--- Comment #4 from bin cheng ---
(In reply to Jiu Fu Guo from comment #3)
> Yes, while the code in adjust_cond_for_loop_until_wrap seems somehow tricky:
>
> /* Only support simple cases for the moment. */
> if (TREE_CODE (iv0->base) !=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101145
--- Comment #2 from bin cheng ---
(In reply to Richard Biener from comment #1)
> This comes up with a pending patch to split loops like
>
> void
> foo (int *a, int *b, unsigned l, unsigned n)
> {
> while (++l != n)
> a[l] = b[l] + 1;
> }
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101173
--- Comment #5 from bin cheng ---
(In reply to Richard Biener from comment #3)
> So we're exchanging the inner two loops
>
> a[1][3] = 8;
> for (int b = 1; b <= 5; b++)
> for (int d = 0; d <= 5; d++)
> for (c = 0; c <= 5; c++)
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100740
bin cheng changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |amker at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499
--- Comment #19 from bin cheng ---
(In reply to bin cheng from comment #18)
> Did some experiments, there are two fallouts after explicitly returning
> false for unsigned/wrapping types in MULT_EXPR/MINUS_EXPR/PLUS_EXPR. One is
> the mentioned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499
--- Comment #18 from bin cheng ---
Did some experiments, there are two fallouts after explicitly returning false
for unsigned/wrapping types in MULT_EXPR/MINUS_EXPR/PLUS_EXPR. One is the
mentioned use of multiple_of_p in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499
--- Comment #14 from bin cheng ---
(In reply to Richard Biener from comment #12)
> So in number_of_iterations_ne it looks like the step 's' is always constant
> which makes me wonder if we can somehow use ranger to tell multiple_of_p
> (type,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499
--- Comment #13 from bin cheng ---
(In reply to Richard Biener from comment #10)
> (In reply to bin cheng from comment #9)
> > Seems we have a long standing bug in fold-const.c:multiple_of_p in case of
> > wrapping types. Take unsigned int as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90078
--- Comment #19 from bin cheng ---
I will check if the latter fix can be easily backported to GCC-9.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499
--- Comment #9 from bin cheng ---
Seems we have a long standing bug in fold-const.c:multiple_of_p in case of
wrapping types. Take unsigned int as an example:
(0xfffc * 0x3) % 0x3 = 0x1
But multiple_of_p returns true here.
The same issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499
bin cheng changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |amker at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98736
--- Comment #6 from bin cheng ---
Shall this be backported to 10/11 later? Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95638
bin cheng changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98736
--- Comment #4 from bin cheng ---
(In reply to bin cheng from comment #3)
> hmm, seems topological order isn't enough for distributing a loop nest, we
> need topological order plus inner loop depth-first.
Well, not really. In this case,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99067
--- Comment #3 from bin cheng ---
Though not sure if the underlying root causes are the same, I think these are
two different issues, at least, they are handled by different parts of code in
IVOPTs.
For the first one, it's a known issue in GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98736
--- Comment #3 from bin cheng ---
hmm, seems topological order isn't enough for distributing a loop nest, we need
topological order plus inner loop depth-first.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99067
bin cheng changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |amker at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97627
--- Comment #12 from bin cheng ---
a. why the loop is considered as infinite
b. we need to skip fake exit edges in niter analysis?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97627
--- Comment #11 from bin cheng ---
(In reply to bin cheng from comment #10)
> hmm,
> For below basic block:
> 128 ;; basic block 4, loop depth 2, maybe hot
> 129 ;;prev block 3, next block 9, flags: (NEW, VISITED)
> 130 ;;pred: 3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97627
--- Comment #10 from bin cheng ---
hmm,
For below basic block:
128 ;; basic block 4, loop depth 2, maybe hot
129 ;;prev block 3, next block 9, flags: (NEW, VISITED)
130 ;;pred: 3 (FALLTHRU,EXECUTABLE)
131 ;;7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97627
--- Comment #9 from bin cheng ---
(In reply to Jakub Jelinek from comment #8)
> Still broken on current 10 branch, as written works fine on the trunk due to
> the C++ FE loop changes.
> Bin, did you have time to look into this yet?
I am very
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98598
--- Comment #4 from bin cheng ---
Didn't go deep into the case.
For simple cases taken as examples, it's possible to interchange the two loops
thus enables loop invariant code motion. Though loop interchange may fail
because of complicated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97627
--- Comment #5 from bin cheng ---
(In reply to Jakub Jelinek from comment #3)
> Started with r9-4145-ga81e2c6240655f60a49c16e0d8bbfd2ba40bba51
Sorry for the breakage. Will fix this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78427
bin cheng changed:
What|Removed |Added
CC||amker at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96201
bin cheng changed:
What|Removed |Added
CC||amker at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95638
--- Comment #14 from bin cheng ---
(In reply to Richard Biener from comment #13)
> GCC 10.2 is released, adjusting target milestone.
Hmm, this should be fixed on GCC10/GCC9. I backported PR95638/PR95804
separately using cherry-pick, so the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96031
--- Comment #2 from bin cheng ---
Interesting case, I see two issues in generated asm. One is the unnecessary
bitwise and, the other is allocating different registers for induction variable
and the base address. However, looks like neither
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95804
--- Comment #11 from bin cheng ---
(In reply to Richard Biener from comment #8)
> Fixed - note it needs to be backported when the PR95638 fix is backported.
I backported PR95638/PR95804 to GCC-10/GCC-9 branches. However, unnecessary to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95804
--- Comment #6 from bin cheng ---
(In reply to Martin Liška from comment #5)
> @Bin: Any news about this?
Patch is approved, will apply soon. Thanks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95638
--- Comment #9 from bin cheng ---
(In reply to Jakub Jelinek from comment #8)
> So fixed on the trunk, waiting for 10 backport?
Sorry, https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95804 is also in this part
which I believe is related to this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95804
--- Comment #2 from bin cheng ---
(In reply to Richard Biener from comment #1)
> Confirmed. We seem to end up with a reduction partition not in the last
> position thus miss some required partition merging.
Sorry for the breakage.
Whew, this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94969
--- Comment #16 from bin cheng ---
(In reply to Richard Biener from comment #15)
> I don't see the commit on the GCC 10 branch nor the GCC 8 branch. Master
> and GCC 9 are fixed though.
Will backport the 10 and 8, thanks for reminding.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95638
--- Comment #6 from bin cheng ---
We call graphds_scc twice to break alias dependence, with alias dependence
edges skipped in the second call. The code (both before and after
r10-7184-ge4e9a59105a81cdd6c1328b0a5ed9fe4cc82840e) tries to rectify
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95638
--- Comment #5 from bin cheng ---
(In reply to Jakub Jelinek from comment #1)
> All I can say is that bisection shows (at least when preprocessed with g++
> 8.3.1 first) that this changed behavior in
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95199
--- Comment #7 from bin cheng ---
(In reply to rguent...@suse.de from comment #6)
> On Thu, 21 May 2020, zhoukaipeng3 at huawei dot com wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95199
> >
> > --- Comment #4 from Kaipeng Zhou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95199
--- Comment #5 from bin cheng ---
(In reply to Richard Biener from comment #1)
> But IVOPTs is supposed to know how to eliminate equal IVs. Maybe it's
> confused
> about the IFN uses?
It's an known issue that IVOPTs has difficulty in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94969
--- Comment #10 from bin cheng ---
Hi，should I backport this and PR95110 to branches? Thanks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95019
--- Comment #3 from bin cheng ---
(In reply to zhongyu...@tom.com from comment #2)
> It is a generic issue for all targets, such as x86, it also don't enpand
Yes, as said it's because SCEV currently doesn't model this, so it's not target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95019
--- Comment #1 from bin cheng ---
Please provide the exact configuration/compilation command lines in bug report
next time, which could save others' time to reproduce. Considering I didn't
touch mips for years.
As for this specific issue, note
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94969
--- Comment #8 from bin cheng ---
Root cause is in build_classic_dist_vector -> constant_access_functions which
adds unit distance vector only in case of constant access function. It should
cover invariant cases. Testing a patch. Thanks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94969
--- Comment #7 from bin cheng ---
(In reply to Richard Biener from comment #5)
> So I think the issue is not dependence testing but loop distribution
> accepting a
> zero dependence distance as OK. Of course dependence analysis is quite
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93674
--- Comment #18 from bin cheng ---
(In reply to Richard Earnshaw from comment #17)
> Has not been backported yet.
Will do it. Thanks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94125
--- Comment #11 from bin cheng ---
(In reply to Richard Biener from comment #10)
> Thanks Bin, fixed on trunk sofar.
Hmm, if it's fine, I will backport this to GCC9.
Thanks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94125
--- Comment #7 from bin cheng ---
Patch at https://gcc.gnu.org/pipermail/gcc-patches/2020-March/542038.html
It's a latent bug exposed by the mentioned alias analysis change, however:
unsigned char b, f;
short d[1][8][1], *g = [0][3][0];
int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94125
--- Comment #5 from bin cheng ---
Thanks for CCing, I will have a look this WE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93674
bin cheng changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |amker at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92244
--- Comment #5 from bin cheng ---
Vectorizer generates following address bases:
_79 = (sizetype) len_6(D);
_80 = _79 + 18446744073709551600;
vectp.14_78 = head_7(D) + _80;
_89 = (sizetype) len_6(D);
_90 = _89 + 18446744073709551600;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93334
--- Comment #2 from bin cheng ---
(In reply to Richard Biener from comment #1)
> Confirmed. The issue is that the overlap would be an issue if the stores
> were using different values like
>
> void test_simple_code(long l, double* mem, long
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93143
--- Comment #7 from bin cheng ---
(In reply to bin cheng from comment #6)
> (In reply to bin cheng from comment #5)
> > (In reply to Martin Sebor from comment #4)
> > > *** Bug 92926 has been marked as a duplicate of this bug. ***
> >
> > I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93143
--- Comment #6 from bin cheng ---
(In reply to bin cheng from comment #5)
> (In reply to Martin Sebor from comment #4)
> > *** Bug 92926 has been marked as a duplicate of this bug. ***
>
> I sent a patch fixing this a
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93143
--- Comment #5 from bin cheng ---
(In reply to Martin Sebor from comment #4)
> *** Bug 92926 has been marked as a duplicate of this bug. ***
I sent a patch fixing this a
https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00920.html
The only question
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: amker at gcc dot gnu.org
Target Milestone: ---
Following code is reduced from cppcoro but is irrelevant to coroutine.
#include
#include
class ipv6_address
{
public:
constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92574
--- Comment #2 from bin cheng ---
Similar to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57534
The original idea was handle this as much as possible in ivopt which is
difficult given ivopt code has lots of (scev/niter) validity checks. In
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85471
bin cheng changed:
What|Removed |Added
CC||amker at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90231
--- Comment #12 from bin cheng ---
(In reply to Jakub Jelinek from comment #10)
> Actually (int) ((ivtmp.11 - (unsigned long) dst_10) / 4), sorry.
> On 64-bit targets this will never be a problem, are you worried about 32-bit
> targets where int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90231
--- Comment #11 from bin cheng ---
(In reply to Richard Biener from comment #9)
> (In reply to bin cheng from comment #7)
> > The orignal iv needs to be represented in debug bind stmt is:
> > 64 IV struct:
> > 65 SSA_NAME: i_18
> > 66
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90231
--- Comment #7 from bin cheng ---
The orignal iv needs to be represented in debug bind stmt is:
64 IV struct:
65 SSA_NAME: i_18
66 Type: int
67 Base: 0
68 Step: 1
69 Biv: Y
70 Overflowness wrto loop niter: No-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91775
--- Comment #6 from bin cheng ---
The address type iv_use has pointer type and 64-bit precision, while iv_cands
added (by ivcanon pass) has unsigned int type. So decremental candidates are
skipped because of following code:
4620│ /* Check if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91137
--- Comment #15 from bin cheng ---
Author: amker
Date: Mon Sep 2 10:10:44 2019
New Revision: 275304
URL: https://gcc.gnu.org/viewcvs?rev=275304=gcc=rev
Log:
Backport from mainline
2019-07-18 Bin Cheng
PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91137
--- Comment #14 from bin cheng ---
Author: amker
Date: Fri Aug 30 11:02:48 2019
New Revision: 275064
URL: https://gcc.gnu.org/viewcvs?rev=275064=gcc=rev
Log:
Backport from mainline
2019-07-18 Bin Cheng
PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91137
--- Comment #13 from bin cheng ---
Author: amker
Date: Wed Jul 24 01:28:33 2019
New Revision: 273754
URL: https://gcc.gnu.org/viewcvs?rev=273754=gcc=rev
Log:
Backport from mainline
2019-07-18 Bin Cheng
PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91137
--- Comment #11 from bin cheng ---
Hi, suppose this patch should be backported to 8/7 if no further issues.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91137
--- Comment #10 from bin cheng ---
Author: amker
Date: Thu Jul 18 08:38:09 2019
New Revision: 273570
URL: https://gcc.gnu.org/viewcvs?rev=273570=gcc=rev
Log:
PR tree-optimization/91137
* tree-ssa-loop-ivopts.c (struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91137
--- Comment #8 from bin cheng ---
(In reply to rguent...@suse.de from comment #7)
> On Mon, 15 Jul 2019, amker at gcc dot gnu.org wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91137
> >
> > --- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91137
--- Comment #6 from bin cheng ---
(In reply to Richard Biener from comment #2)
>
> and I can very well imagine we're getting confused by find_base_term
> logic here.
>
> There's logic in IVOPTs to not generate IVs based on two different
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91137
--- Comment #5 from bin cheng ---
Will try to find some time this WE, sorry for delaying.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90240
--- Comment #12 from bin cheng ---
(In reply to Richard Biener from comment #11)
> Is this now fixed?
yes, fixed on trunk. Only if it should be backported to GCC-9?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57534
--- Comment #34 from bin cheng ---
So we could have three different addressing modes here.
1. What we have now:
leaq0(,%rbp,8), %rax
movsd 8(%rbx,%rax), %xmm0
addsd (%rbx,%rbp,8), %xmm0
addq$8, %rbp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90078
--- Comment #14 from bin cheng ---
Author: amker
Date: Wed May 8 11:37:45 2019
New Revision: 271008
URL: https://gcc.gnu.org/viewcvs?rev=271008=gcc=rev
Log:
PR tree-optimization/90078
* tree-ssa-loop-ivopts.c (INFTY): Increase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90240
--- Comment #10 from bin cheng ---
Author: amker
Date: Wed May 8 11:24:38 2019
New Revision: 271007
URL: https://gcc.gnu.org/viewcvs?rev=271007=gcc=rev
Log:
PR tree-optimization/90240
* tree-ssa-loop-ivopts.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57534
bin cheng changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |amker at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90078
--- Comment #13 from bin cheng ---
Reverted 270500 on trunk too for easier backport to GCC9.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90078
--- Comment #12 from bin cheng ---
Author: amker
Date: Tue Apr 30 03:00:59 2019
New Revision: 270673
URL: https://gcc.gnu.org/viewcvs?rev=270673=gcc=rev
Log:
PR tree-optimization/90240
Revert:
2019-04-23 Bin Cheng
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90240
--- Comment #9 from bin cheng ---
Author: amker
Date: Tue Apr 30 03:00:59 2019
New Revision: 270673
URL: https://gcc.gnu.org/viewcvs?rev=270673=gcc=rev
Log:
PR tree-optimization/90240
Revert:
2019-04-23 Bin Cheng
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90270
--- Comment #11 from bin cheng ---
For the record, this test reveals another issue that original iv cand is not
considered:
Group 0:
Type: REFERENCE ADDRESS
Use 0.0:
At stmt:_1 = final_counts[i_21];
At pos:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90270
--- Comment #10 from bin cheng ---
(In reply to Richard Biener from comment #9)
> (In reply to bin cheng from comment #7)
> > Also, when calling move_fixed_address_to_symbol, fixed_address_object_p
> > looks too restricted, it only considers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90270
--- Comment #7 from bin cheng ---
Also, when calling move_fixed_address_to_symbol, fixed_address_object_p looks
too restricted, it only considers link time constant address. In this case,
it's an array object in stack.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90270
--- Comment #6 from bin cheng ---
(In reply to Andrew Pinski from comment #5)
> (In reply to bin cheng from comment #4)
> > On AArch64, iovpts generates following code:
> >[local count: 954449108]:
> > # crc_20 = PHI
> > # ivtmp.5_18 =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90270
--- Comment #4 from bin cheng ---
On AArch64, iovpts generates following code:
[local count: 954449108]:
# crc_20 = PHI
# ivtmp.5_18 = PHI <1(2), ivtmp.5_17(5)>
_19 = _counts + 18446744073709551612;
_1 = MEM[base: _19, index:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90240
--- Comment #8 from bin cheng ---
Patch proposed at:
https://gcc.gnu.org/ml/gcc-patches/2019-04/msg01101.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90240
--- Comment #4 from bin cheng ---
(In reply to Jakub Jelinek from comment #3)
> Graphite, so IMHO not a release blocker.
but the issue is critical, it could happen with general optimization level for
loop nest with huge scaling factor.
So,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90240
--- Comment #2 from bin cheng ---
Also, cost in inner loop is scaled by big number:
Scaling cost based on bb prob by 1.00: 0 (scratch: 0) -> 0 (1/1)
Scaling cost based on bb prob by 1.00: 32 (scratch: 0) -> 32 (1/1)
Scaling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90240
bin cheng changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |amker at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90231
bin cheng changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |amker at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90021
--- Comment #5 from bin cheng ---
(In reply to Jakub Jelinek from comment #4)
> From what I can see, a fix for this has been acked 11 days ago:
> https://gcc.gnu.org/ml/gcc-patches/2019-04/msg00413.html
> Bin, are you going to commit it?
I just
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90078
--- Comment #9 from bin cheng ---
Author: amker
Date: Tue Apr 23 04:07:46 2019
New Revision: 270500
URL: https://gcc.gnu.org/viewcvs?rev=270500=gcc=rev
Log:
PR tree-optimization/90078
* tree-ssa-loop-ivopts.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86153
bin cheng changed:
What|Removed |Added
CC||amker at gcc dot gnu.org
--- Comment #16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90078
--- Comment #6 from bin cheng ---
(In reply to Martin Liška from comment #5)
> (In reply to bin cheng from comment #4)
> > In get_scaled_computation_cost_at, we have very big ratio between
> > bb_count/loop_count:
> >
> > (gdb) p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90078
--- Comment #4 from bin cheng ---
In get_scaled_computation_cost_at, we have very big ratio between
bb_count/loop_count:
(gdb) p data->current_loop->latch->count
$50 = {static n_bits = 61, static max_count =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90021
--- Comment #2 from bin cheng ---
We have {{0, +, 1}_6, +, 1}_4 in this case, and _6 is an outer loop of
loop_nest. Function add_multivariate_self_dist was intentionally skipped in
PR89725 patch, but control flow gets to it because
1) In
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90021
--- Comment #1 from bin cheng ---
Sorry for the breakage, I will have a look.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89725
--- Comment #11 from bin cheng ---
In case of data reference has more access functions than loop_nest of data
dependence analysis, we need to skip/ignore access functions corresponding
loops not in the loop_nest. So far this only happens in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89725
--- Comment #9 from bin cheng ---
(In reply to Richard Biener from comment #8)
> (In reply to bin cheng from comment #7)
> > I am testing below simple fix, it bypass access functions doesn't belong to
> > analyzing loop_nest:
> >
> > diff --git
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89725
--- Comment #7 from bin cheng ---
I am testing below simple fix, it bypass access functions doesn't belong to
analyzing loop_nest:
diff --git a/gcc/tree-data-ref.c b/gcc/tree-data-ref.c
index e536b463e96..410d44f43e8 100644
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89725
--- Comment #6 from bin cheng ---
(In reply to Richard Biener from comment #4)
> I think the issue is that the DDR is bogus - loop interchange computes
> data-refs
> for a deeper nest (including some outer loops) than it ends up doing
>
Assignee: unassigned at gcc dot gnu.org
Reporter: amker at gcc dot gnu.org
Target Milestone: ---
Hi,
This is the code sample from scovit@IRC:
struct ciao { long a; long b; };
//__declspec(noinline)
__attribute((noinline))
struct ciao square(int num) {
struct ciao beta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89834
--- Comment #5 from bin cheng ---
Thanks very much for reporting and fixing the issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89487
--- Comment #9 from bin cheng ---
(In reply to Jakub Jelinek from comment #8)
> *** Bug 89731 has been marked as a duplicate of this bug. ***
Hi Jakub, is this (and the duplication) fixed by the previous patches or the
issue is still there?
1 - 100 of 827 matches
Mail list logo
