Assignee: unassigned at gcc dot gnu.org
Reporter: rdapp at linux dot vnet.ibm.com
Target Milestone: ---
Target: s390, x86
While inspecting loop generation code on s390, I saw ivopts choose an IV
candidate which does something peculiar. On x86 the same candidate is never
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69526
--- Comment #2 from rdapp at linux dot vnet.ibm.com ---
Ok, that's sensible but why is the - 1 necessary in the first place?
n_5 - 1 can only underflow if n_5 == 0 which is checked by
testl %edx, %edx
before. This is in a previous basic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69526
--- Comment #5 from rdapp at linux dot vnet.ibm.com ---
I still don't quite get why the "n - 1" is needed. Do we need it to possibly
have an exit condition like
if (i != n-1) or
if (i <= n-1)?
Am I missing something really obvious here?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69526
--- Comment #7 from rdapp at linux dot vnet.ibm.com ---
(In reply to amker from comment #6)
> It comes from loop niter analysis, as in may_eliminate_iv, we have:
>
> (gdb) call debug_generic_expr(desc->niter)
> n_5(D) + 42949672
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69526
--- Comment #10 from rdapp at linux dot vnet.ibm.com ---
Created attachment 38144
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38144&action=edit
Tentative patch for VRP and loop-doloop
Meanwhile I found the time to implement a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69526
--- Comment #13 from rdapp at linux dot vnet.ibm.com ---
Created attachment 38535
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38535&action=edit
VRP/match.pd patch
Found some time again and hacked together a fix for match.pd and V
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69526
--- Comment #15 from rdapp at linux dot vnet.ibm.com ---
Thanks for the suggestions. The omission of the inner op was actually more or
less on purpose as I intended to capture the
(convert @inner)
in order to access @inner's value range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69526
--- Comment #17 from rdapp at linux dot vnet.ibm.com ---
(In reply to Marc Glisse from comment #16)
> (In reply to rdapp from comment #15)
> > Is there a simple method to access @inner when
> > capturing
> > (outer_op (conve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80925
--- Comment #3 from rdapp at linux dot vnet.ibm.com ---
Strange, my tests didn't show new failures on Power7. I'll have a look, perhaps
the build settings were wrong.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80925
--- Comment #5 from rdapp at linux dot vnet.ibm.com ---
I quickly built trunk without bootstrap on power7 BE
("--enable-languages="c,c++,fortran" --disable-multilib --disable-bootstrap")
and still get no new fails. D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80925
--- Comment #7 from rdapp at linux dot vnet.ibm.com ---
I could reproduce the fails on a power8 machine now.
Looking at the vect-28.c FAIL now - the loop to be vectorized is:
for (i = 0; i < N; i++)
{
ia[i+off] = 5;
}
It st
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80925
--- Comment #9 from rdapp at linux dot vnet.ibm.com ---
I built --with-cpu=power7 and still see TARGET_EFFICIENT_UNALIGNED_VSX == true
in the backend which causes unaligned stores to have costs of 1. On my power7
system
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80925
--- Comment #16 from rdapp at linux dot vnet.ibm.com ---
(In reply to seurer from comment #14)
> spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test/gcc/xgcc
> -B/home/seurer/gcc/build/gcc-test/gcc/
> /home/seurer/gcc/gcc-test/gcc/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81362
--- Comment #1 from rdapp at linux dot vnet.ibm.com ---
Could you provide the vectorizer dump (-fdump-tree-vect-details)? The generated
assembly might also be interesting as well as the exact command line for
building (in the test suite logs). I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81362
--- Comment #5 from rdapp at linux dot vnet.ibm.com ---
Ah, npeel is set by vect_peeling_hash_get_lowest_cost although the
corresponding dr is not used afterwards. It should be save to get rid of the
npeel parameter since we use the returned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81362
--- Comment #6 from rdapp at linux dot vnet.ibm.com ---
Created attachment 41715
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41715&action=edit
Tentative patch
Removed the npeel function argument, also removed body_cost_vec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78468
rdapp at linux dot vnet.ibm.com changed:
What|Removed |Added
CC||rdapp at linux dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77283
--- Comment #11 from rdapp at linux dot vnet.ibm.com ---
Any progress on this? The patch fixes the problem for s390x (no performance
regressions), but without it we see the regression in SPEC2006's libquantum all
the time, I guess the sa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77283
--- Comment #15 from rdapp at linux dot vnet.ibm.com ---
The updated patch fixes libquantum on s390 so PR77366 might indeed be to
simplified to check for that, but it was unrolled before r238005. Addressing
libquantum is more important, of course.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83069
rdapp at linux dot vnet.ibm.com changed:
What|Removed |Added
CC||rdapp at linux dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69526
--- Comment #19 from rdapp at linux dot vnet.ibm.com ---
(In reply to rguent...@suse.de from comment #18)
>
The match.pd patch is slowly assuming shape... Two things however I'm still
unsure about:
1.
An existing rule in match.pd ch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69526
rdapp at linux dot vnet.ibm.com changed:
What|Removed |Added
Version|6.0 |unknown
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69526
--- Comment #24 from rdapp at linux dot vnet.ibm.com ---
Created attachment 38775
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38775&action=edit
Updated patch and test, match.pd/VRP
(In reply to amker from comment #23)
> Hmm, n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69526
--- Comment #25 from rdapp at linux dot vnet.ibm.com ---
Created attachment 38875
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38875&action=edit
Updated patch and test, math.pd/VRP
Some cleanups and fixes, the patch can now hand
: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: rdapp at linux dot vnet.ibm.com
CC: krebbel at gcc dot gnu.org
Target Milestone: ---
Host: s390
Target: s390
Since 2ac4967f49a70e1bd0bb28a142324f527dac3743 the following loop is
25 matches
Mail list logo
