https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69042
Richard Biener changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69042
--- Comment #13 from amker at gcc dot gnu.org ---
Simple summary.
The test case provided in this PR is resolved by the two patches, but the
problem still exists if the first function in compilation unit triggers the
issue. This is because x86's i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69042
--- Comment #12 from amker at gcc dot gnu.org ---
The above two patches actually doesn't fix the problem, but I think it covers
the problem by bringing back the old behavior.
So Ilya, could you please check that status of the regression? Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69042
--- Comment #11 from amker at gcc dot gnu.org ---
Author: amker
Date: Wed Mar 23 15:26:43 2016
New Revision: 234430
URL: https://gcc.gnu.org/viewcvs?rev=234430&root=gcc&view=rev
Log:
PR tree-optimization/69042
* params.def (PARAM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69042
--- Comment #10 from amker at gcc dot gnu.org ---
Author: amker
Date: Wed Mar 23 15:24:20 2016
New Revision: 234429
URL: https://gcc.gnu.org/viewcvs?rev=234429&root=gcc&view=rev
Log:
PR tree-optimization/69042
* tree-ssa-loop-ivo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69042
--- Comment #9 from amker at gcc dot gnu.org ---
(In reply to amker from comment #8)
> Though adding candidate with offset stripped from base helps this case, it
> causes other regressions which I need to understand.
I can confirm that one major
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69042
--- Comment #8 from amker at gcc dot gnu.org ---
Though adding candidate with offset stripped from base helps this case, it
causes other regressions which I need to understand.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69042
--- Comment #7 from amker at gcc dot gnu.org ---
If I add back the candidate, ivopt can fix attached case, but it still can't
handle a slightly tuned case as below:
extern const int indexes[];
int bar (int code);
int
foo (short *data)
{
regis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69042
Richard Biener changed:
What|Removed |Added
Target||i?86-*-*
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69042
--- Comment #5 from amker at gcc dot gnu.org ---
(In reply to Andrew Pinski from comment #1)
> Confirmed, even on aarch64 too. Replacing the asm with:
>
> asm("":::"x0","x1","x2","x3","x4","x5","x6","x7","x8","x9","x10","x11","x12",
> "x13","x1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69042
--- Comment #4 from amker at gcc dot gnu.org ---
Still need to check if aarch64 is affected by this register pressure issue. It
shouldn't because we don't support symbol in addressing mode and need to
compute it outside mem ref anyway.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69042
--- Comment #3 from amker at gcc dot gnu.org ---
(In reply to amker from comment #2)
> For iv use:
> use 0
> address
> in statement _9 = indexes[i_23];
>
> at position indexes[i_23]
> type const int *
> base (const int *) (&indexes + 4)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69042
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69042
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
Target Milestone|-
14 matches
Mail list logo
