https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88963
--- Comment #12 from Richard Biener ---
Author: rguenth
Date: Fri May 3 10:39:56 2019
New Revision: 270844
URL: https://gcc.gnu.org/viewcvs?rev=270844&root=gcc&view=rev
Log:
2019-05-03 Richard Biener
PR tree-optimization/88963
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88963
--- Comment #11 from Richard Biener ---
The issue RTL expansion spills is the inner MEM_REF is expanded to
(mem:BLK (reg/v/f:DI 88 [ a ]) [1 *a_7(D)+0 S64 A256])
and somehow
if (MEM_P (to_rtx))
{
/* If the fie
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88963
--- Comment #10 from Devin Hussey ---
I also want to add that aarch64 shouldn't even be spilling; it has 32 NEON
registers and with 128 byte vectors it should only use 24.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88963
--- Comment #9 from Devin Hussey ---
(In reply to Andrew Pinski from comment #6)
> Try using 128 (or 256) and you might see that aarch64 falls down similarly.
yup. Oof.
test:
sub sp, sp, #560
stp x29, x30, [sp]
m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88963
--- Comment #8 from Richard Biener ---
You can try the attached patch, it "fixes" the issue on the GIMPLE side but
appearantly the BIT_FIELD_REF stores go a weird path during RTL expansion
and so we end up spilling again.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88963
--- Comment #7 from Marc Glisse ---
See PR 55266 (and several others).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88963
--- Comment #6 from Andrew Pinski ---
Try using 128 (or 256) and you might see that aarch64 falls down similarly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88963
--- Comment #5 from Andrew Pinski ---
(In reply to Devin Hussey from comment #4)
> Strangely, this doesn't seem to affect the ARM or aarch64 backends, although
> I am on a December build (specifically Dec 29). 8.2 is also unaffected.
This is due
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88963
Devin Hussey changed:
What|Removed |Added
CC||husseydevin at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88963
--- Comment #3 from Jakub Jelinek ---
Yeah, I've noticed that already when working on __builtin_convertvector, we
don't really do much TER for the oversized vector SSA_NAMEs and force them into
stack all the time. Wonder if we couldn't do kind o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88963
--- Comment #2 from Richard Biener ---
Created attachment 45489
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45489&action=edit
untested patch
forwprop patch I was playing with.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88963
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
CC|
12 matches
Mail list logo
