https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65546
--- Comment #7 from Bill Schmidt ---
Author: wschmidt
Date: Sat Jan 30 01:20:27 2016
New Revision: 233007
URL: https://gcc.gnu.org/viewcvs?rev=233007&root=gcc&view=rev
Log:
2016-01-29 Bill Schmidt
PR target/65546
* gcc.dg/vec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65546
Bill Schmidt changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63805
Bill Schmidt changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #8 from Bill Schmidt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63805
--- Comment #9 from Bill Schmidt ---
Same question for Markus. Sorry for conflating the two of you. :)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63805
Bill Schmidt changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #11 from Bill Schmidt --
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63805
--- Comment #14 from Bill Schmidt ---
>From correspondence with Uli Weigand, it appears that the code is valid even
with misaligned data, but a locking implementation is needed. I haven't
checked whether other targets succeed here; that would be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69611
--- Comment #8 from Bill Schmidt ---
Andreas, if this is complete, please move to RESOLVED/FIXED state. Thanks!
-optimization
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: wschmidt at gcc dot gnu.org
CC: dje at gcc dot gnu.org, hubicka at gcc dot gnu.org
Target Milestone: ---
Target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68404
--- Comment #9 from Bill Schmidt ---
Finally got back to this for a bit. I've tracked the problem down to the
register renaming pass. I suspect it's having trouble with the
fusion_gpr_load_di pattern:
(insn 452 236 243 19 (set (reg:DI 9 9)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68404
--- Comment #10 from Bill Schmidt ---
Looking at scan_rtx_address () in regrename.c, it indeed looks like a PLUS
nested inside a PLUS isn't handled. I'm not sure if this is a deficiency in
regrename.c, or whether the definition of fusion_gpr_loa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68404
Bill Schmidt changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69738
Bill Schmidt changed:
What|Removed |Added
Status|ASSIGNED|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65313
--- Comment #5 from Bill Schmidt ---
What's the status here? Did Jakub's patch fix the underlying problem, or does
this still need investigation?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65313
--- Comment #7 from Bill Schmidt ---
OK, thanks. We'll get somebody looking at this, then.
-optimization
Severity: normal
Priority: P3
Component: target
Assignee: wschmidt at gcc dot gnu.org
Reporter: wschmidt at gcc dot gnu.org
CC: dje.gcc at gmail dot com, uweigand at gcc dot gnu.org
Target Milestone: ---
Target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69868
Bill Schmidt changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69868
--- Comment #2 from Bill Schmidt ---
Created attachment 37759
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37759&action=edit
Tentative patch (needs refactoring)
Attaching a tested patch that solves the problem for this case without
regre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69868
Bill Schmidt changed:
What|Removed |Added
Attachment #37759|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61397
Bill Schmidt changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
||dje.gcc at gmail dot com,
||seurer at linux dot
vnet.ibm.com,
||wschmidt at gcc dot gnu.org
Resolution|FIXED |---
--- Comment #8 from Bill Schmidt ---
The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69613
--- Comment #9 from Bill Schmidt ---
Executing on host: /home/wschmidt/gcc/build/gcc-mainline-test/gcc/xgcc
-B/home/wschmidt/gcc/build/gcc-mainline-test/gcc/
/home/wschmidt/gcc/gcc-mainline-test/gcc/testsuite/gcc.dg/torture/pr69613.c
-fno-diagno
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69613
--- Comment #11 from Bill Schmidt ---
Will check now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69613
--- Comment #12 from Bill Schmidt ---
Jakub, success. Bootstrap on powerpc64le-unknown-linux-gnu with the attachment
from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69896#c8 clears both PR69896
and this one:
2c2
< LAST_UPDATED: Fri Feb 26 23:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70011
--- Comment #3 from Bill Schmidt ---
I'll have a look at the differences in output from GCC 5 and GCC 6.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70011
Bill Schmidt changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
at gcc dot gnu.org |wschmidt at gcc dot
gnu.org
--- Comment #5 from Bill Schmidt ---
I've verified such a fix for LE (P8) and BE (P7, P8). I'll get the patch
submitted.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70011
--- Comment #6 from Bill Schmidt ---
Author: wschmidt
Date: Tue Mar 1 04:14:15 2016
New Revision: 233840
URL: https://gcc.gnu.org/viewcvs?rev=233840&root=gcc&view=rev
Log:
2016-02-29 Bill Schmidt
PR target/70011
* gcc.dg/vec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70011
Bill Schmidt changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15826
--- Comment #15 from Bill Schmidt ---
My preference is to see the test properly resolved. :) I don't think you
should just XFAIL the powerpc64le case without understanding why it fails, as
that tends to leave the XFAIL in place forever.
Here is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69868
--- Comment #4 from Bill Schmidt ---
Author: wschmidt
Date: Fri Mar 4 03:13:30 2016
New Revision: 233957
URL: https://gcc.gnu.org/viewcvs?rev=233957&root=gcc&view=rev
Log:
2016-03-03 Bill Schmidt
PR target/69868 + swap optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70130
--- Comment #1 from Bill Schmidt ---
It's not clear to me from the report whether you have run this only on
big-endian systems, or whether little-endian has been tried for Power8 (with
-mcpu=power8). Can you please clarify?
I ask because the -m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70098
--- Comment #6 from Bill Schmidt ---
The title mischaracterizes the problem. There is a problem in IRA, which
causes a failure to show up either in LRA or in reload.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70130
--- Comment #3 from Bill Schmidt ---
I looked at the test case under the debugger today. Both the SLP-vectorized
version of the loop, and the unvectorized version, appear to work correctly.
The code is straightforward and not input-dependent, s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70130
--- Comment #5 from Bill Schmidt ---
We also verified that the vectorized version of the loop is never entered
during the application, since the output array is never properly aligned.
Other experiments also point to a linker issue. When compil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69493
--- Comment #3 from Bill Schmidt ---
That's interesting. We have some other examples of similar issues we should
check as well before closing this. I'll take a look in a bit.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69493
--- Comment #4 from Bill Schmidt ---
I still see the problem with:
GCC: (GNU) 6.0.0 20160309 (experimental) [trunk revision 234085]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57955
--- Comment #15 from Bill Schmidt ---
I tried implementing Jakub's suggestion to have CONSTANT_ALIGNMENT return 128
for large constructors. This doesn't fix the r201264 version of the test case,
which still generates fairly horrid code. The use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70107
--- Comment #2 from Bill Schmidt ---
Could not confirm with trunk r234476 on powerpc64le dated 2016-03-24. Can you
please retry with something at least that recent?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70107
--- Comment #3 from Bill Schmidt ---
Also, on latest GCC 5 and GCC 4.9, the front end objects:
wschmidt@genoa:~/src$ $GCC_INSTALL/bin/g++ -w -c -mcpu=power8 pr70107.ii
pr70107.ii:3:46: error: expected type-specifier before 'decltype'
auto ope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70457
--- Comment #3 from Bill Schmidt ---
So we have an unreachable call to pow with the wrong number of arguments. I
suppose the expansion logic for builtin_pow should tolerate this situation and
just do nothing with it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70457
--- Comment #4 from Bill Schmidt ---
(I should say, presumably unreachable. This source code looks pretty dicey in
the first place, but nonetheless we should probably tolerate it at this stage
of optimization.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70457
--- Comment #5 from Bill Schmidt ---
Created attachment 38156
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38156&action=edit
Patch that permits this to compile
The attached patch allows the compilation to succeed in spite of the incorrec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70457
Bill Schmidt changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |wschmidt at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70457
--- Comment #8 from Bill Schmidt ---
The tree-inline part only shows up after fixing the part in
tree-ssa-math-opts.c, where the initial failure occurs. The DECL is already
encoded as a BUILT_IN_POW by the time we get that far.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70457
--- Comment #10 from Bill Schmidt ---
Ok, sounds good. I have vacation this afternoon, but will revisit this over
the weekend or Monday.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70457
--- Comment #11 from Bill Schmidt ---
Jakub, thanks, I've verified that works and makes for a much better patch.
Will post shortly on gcc-patches.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70457
--- Comment #12 from Bill Schmidt ---
Author: wschmidt
Date: Mon Apr 4 15:42:19 2016
New Revision: 234716
URL: https://gcc.gnu.org/viewcvs?rev=234716&root=gcc&view=rev
Log:
[gcc]
2016-04-04 Bill Schmidt
Jakub Jelinek
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70457
--- Comment #13 from Bill Schmidt ---
Author: wschmidt
Date: Mon Apr 4 15:45:59 2016
New Revision: 234717
URL: https://gcc.gnu.org/viewcvs?rev=234717&root=gcc&view=rev
Log:
[gcc]
2016-04-04 Bill Schmidt
Jakub Jelinek
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70457
--- Comment #14 from Bill Schmidt ---
Author: wschmidt
Date: Mon Apr 4 15:47:51 2016
New Revision: 234718
URL: https://gcc.gnu.org/viewcvs?rev=234718&root=gcc&view=rev
Log:
[gcc]
2016-04-04 Bill Schmidt
Jakub Jelinek
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70457
--- Comment #15 from Bill Schmidt ---
Matthias, the code is now fixed everywhere upstream. Do you need a merge into
ibm/gcc-5-branch?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70457
Bill Schmidt changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65479
--- Comment #14 from Bill Schmidt ---
I wonder if this is just support that hasn't been updated in the GCC copy of
libsanitizer. I recall fixing this bug (or one very similar to it) on the
Clang side in 2015. There is some Power-specific logic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65479
--- Comment #15 from Bill Schmidt ---
Yes, it seems likely that this is due to this patch being missing from GCC 5.3:
http://reviews.llvm.org/D11552
The fix is present in trunk, so this should be fixed with a backport.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65479
Bill Schmidt changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70130
--- Comment #14 from Bill Schmidt ---
Unfortunately the patch doesn't help with Alan's streamlined test. It still
fails (tested on powerpc64le).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70130
--- Comment #15 from Bill Schmidt ---
Created attachment 38252
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38252&action=edit
Vectorization dump without patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70130
--- Comment #16 from Bill Schmidt ---
Created attachment 38253
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38253&action=edit
Vectorization dump with patch applied
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70130
--- Comment #17 from Bill Schmidt ---
Though as I look at it, the "p" field is undefined in Alan's test. Let me fix
that and see what we get.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70130
--- Comment #18 from Bill Schmidt ---
Never mind, it would get zero initialization, and specifying that directly
doesn't help.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70130
Bill Schmidt changed:
What|Removed |Added
Summary|[6 Regression] h264ref |[6 Regression] h264ref
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70130
--- Comment #20 from Bill Schmidt ---
Created attachment 38257
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38257&action=edit
Vectorization dump for r224220
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70130
--- Comment #21 from Bill Schmidt ---
Created attachment 38258
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38258&action=edit
Vectorization dump for r224221
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70130
--- Comment #22 from Bill Schmidt ---
The most suspicious thing I see in r224221 is following the gap adjustment:
vect__39.29_261 = REALIGN_LOAD ;
vectp_s.20_260 = vectp_s.20_278 + 18446744073709551560;
vect__39.30_247 = VEC_PERM_EXPR ;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70130
--- Comment #25 from Bill Schmidt ---
I've verified the patch indeed fixes the test from c#11. Regstrap in progress.
One nit: The parentheses in the proposed patch are slightly wrong, should be:
&& (LOOP_VINFO_VECT_FACTOR (loop_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70130
--- Comment #26 from Bill Schmidt ---
Ah, I see from IRC that Alan has already done a regstrap and reported no
failures.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70130
--- Comment #27 from Bill Schmidt ---
However, that was with the parentheses misplaced. I've completed a bootstrap
and regression test on powerpc64le-unknown-linux-gnu with this corrected, and
everything is still fine.
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: wschmidt at gcc dot gnu.org
CC: dje at gcc dot gnu.org, rguenth at gcc dot gnu.org
Target Milestone: ---
Target: powerpc*-unknown-linux-gnu
As discussed
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: wschmidt at gcc dot gnu.org
CC: dje at gcc dot gnu.org, segher at gcc dot gnu.org
Target Milestone: ---
Target: powerpc64le-unknown-linux-gnu
The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70761
Bill Schmidt changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70098
Bill Schmidt changed:
What|Removed |Added
CC||markos at freevec dot org
--- Comment #9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70098
--- Comment #10 from Bill Schmidt ---
Author: wschmidt
Date: Mon Apr 25 22:28:36 2016
New Revision: 235423
URL: https://gcc.gnu.org/viewcvs?rev=235423&root=gcc&view=rev
Log:
[gcc]
2016-04-25 Bill Schmidt
Backport from mainline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70098
--- Comment #11 from Bill Schmidt ---
Author: wschmidt
Date: Mon Apr 25 22:29:49 2016
New Revision: 235424
URL: https://gcc.gnu.org/viewcvs?rev=235424&root=gcc&view=rev
Log:
[gcc]
2016-04-25 Bill Schmidt
Backport from mainline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70826
--- Comment #2 from Bill Schmidt ---
I don't know the register-renames code at all -- does it update debug
information when it replaces registers? Sounds like gdb is getting stale
results for which register represents a memory value.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70928
--- Comment #1 from Bill Schmidt ---
Short sequences for the rest of -32 to 31 are possible also. The splats can be
done as follows.
x even, x in [-32,-18] U [16,30]:
vspltis[bhw] t, x
vaddu[bhw]m y, t, t
x odd, x in [17,31]:
vsplti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70957
Bill Schmidt changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |wschmidt at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70957
Bill Schmidt changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70957
--- Comment #3 from Bill Schmidt ---
Configuration for the two compilers used:
$GCC_SRC/configure --enable-__cxa_atexit
--enable-languages=c,c++,fortran,objc,obj-c++,go --with-cpu=power7
--disable-libsanitizer --with-gmp=/home/wschmidt/gcc-libs/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70957
--- Comment #4 from Bill Schmidt ---
The other odd thing is that we fail only on the signed and unsigned long long
cases, and all of the other variants work.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70957
--- Comment #5 from Bill Schmidt ---
I applied the same patch to gcc-6-branch, and the test works correctly on a
Power7 machine. Thus we appear to be exposing a recent problem introduced on
trunk. I'll try to bisect this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70957
--- Comment #6 from Bill Schmidt ---
The test also passed on P7 at the time I committed the patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70957
Bill Schmidt changed:
What|Removed |Added
Status|NEW |UNCONFIRMED
Ever confirmed|1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70957
--- Comment #8 from Bill Schmidt ---
Looks like it also did not fail in the latest gcc-testresults Power7 BE run.
Going to stop looking at this unless/until it shows up again.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70963
--- Comment #2 from Bill Schmidt ---
The xxswapd's are a bit of a red herring. These are part of the little-endian
normalization code that are required with the funky lxvd2x and stxvd2x
instructions. The problem appears to be the register assig
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70963
--- Comment #3 from Bill Schmidt ---
Note also that your asm constraints are wrong. You need VSX registers, not
Altivec registers, so you should be using the "wa" constraint instead of the
"v" constraint. This is why you get some apparently wro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70963
--- Comment #4 from Bill Schmidt ---
OK, there is an obvious bug in the define_expand for vsx_xvcvdpsxds_scale. If
the scale factor is 0, wrong code is always generated. I'll get a patch going.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70963
--- Comment #6 from Bill Schmidt ---
Author: wschmidt
Date: Tue May 10 14:27:12 2016
New Revision: 236082
URL: https://gcc.gnu.org/viewcvs?rev=236082&root=gcc&view=rev
Log:
[gcc]
2016-05-10 Bill Schmidt
PR target/70963
* con
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70963
--- Comment #7 from Bill Schmidt ---
Author: wschmidt
Date: Tue May 10 16:07:04 2016
New Revision: 236089
URL: https://gcc.gnu.org/viewcvs?rev=236089&root=gcc&view=rev
Log:
[gcc]
2016-05-10 Bill Schmidt
Backport from mainline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70963
--- Comment #8 from Bill Schmidt ---
Author: wschmidt
Date: Tue May 10 16:09:28 2016
New Revision: 236091
URL: https://gcc.gnu.org/viewcvs?rev=236091&root=gcc&view=rev
Log:
[gcc]
2016-05-10 Bill Schmidt
Backport from mainline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70963
--- Comment #9 from Bill Schmidt ---
Author: wschmidt
Date: Tue May 10 17:24:32 2016
New Revision: 236097
URL: https://gcc.gnu.org/viewcvs?rev=236097&root=gcc&view=rev
Log:
[gcc]
2016-05-10 Bill Schmidt
Backport from mainline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70963
Bill Schmidt changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44382
--- Comment #12 from Bill Schmidt ---
I'd propose that this bug can now be closed. If nobody objects, I'll do that
later this week.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71050
Bill Schmidt changed:
What|Removed |Added
CC||dje at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71050
--- Comment #3 from Bill Schmidt ---
Sorry, accidentally saved before finishing my thoughts.
How do we "inform" the middle-end that a DI subreg of a DF is very expensive?
This differs wildly by processor for us. We "can" always do the subreg,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70825
Bill Schmidt changed:
What|Removed |Added
Target|x86_64, aarch64 |x86_64, aarch64, powerpc64*
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44382
Bill Schmidt changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71050
--- Comment #6 from Bill Schmidt ---
Yes, I see your point -- even if you query the RTX cost of the subreg, we're
just going to tell you it's one insn since the true expense doesn't show up
until reload. Seems like some invention will be require
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71050
--- Comment #8 from Bill Schmidt ---
Even this test case isn't truly horrible for real-world code (it looks nastier
than it is, as stack stores tend to have minimal real cost). This is an issue
only on "older" processors; it's just that a lot of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71050
--- Comment #10 from Bill Schmidt ---
Great, thanks, Pat! Let's hold off for now, as Segher is checking out some
ideas.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71309
Bill Schmidt changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70957
Bill Schmidt changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|2016-05-06 00:00:0
601 - 700 of 1697 matches
Mail list logo
