https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86209
--- Comment #15 from Andrew Pinski ---
Hmm, I wonder why expand is generating subreg in place for the add in one case
and not the other.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86209
Richard Earnshaw changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|sameerad at gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86209
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86209
sameerad at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |sameerad at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86209
--- Comment #13 from Ramana Radhakrishnan ---
Sameera,
If you are working on this , can you please assign this to yourself ?
Ramana
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86209
Ramana Radhakrishnan changed:
What|Removed |Added
Keywords||missed-optimization
S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86209
--- Comment #11 from Richard Earnshaw ---
(In reply to sameerad from comment #10)
> > subus:
> >ldr w0, [w0]
> >add w0, w0, w0, lsr #16
> >uxth w0, w0
> >ret
>
> This is interesting way in which load store combining can be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86209
--- Comment #10 from sameerad at gcc dot gnu.org ---
> subus:
>ldr w0, [w0]
>add w0, w0, w0, lsr #16
>uxth w0, w0
>ret
This is interesting way in which load store combining can be enhanced further.
I will try to figure out i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86209
--- Comment #9 from Richard Earnshaw ---
(In reply to ktkachov from comment #7)
> The other thing to consider with merging loads is how the result is used.
> In your example if you merge the 16-bit loads into a single 32-bit register
> load you'l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86209
--- Comment #8 from sameerad at gcc dot gnu.org ---
Currently, we are not planning to restrict load/store merging to specific
cases. Restricted merging of loads and stores is already handled by GIMPLE
store-merging pass.
We are combining loads/st
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86209
--- Comment #7 from ktkachov at gcc dot gnu.org ---
The other thing to consider with merging loads is how the result is used.
In your example if you merge the 16-bit loads into a single 32-bit register
load you'll have to add instructions to extra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86209
--- Comment #6 from Richard Biener ---
Since you are trying to combine loads you may run afoul of STLF issues on
modern CPU architectures which generally cannot forward from separate stores to
a
larger load. Not sure if that applies to ARM but I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86209
--- Comment #5 from sameerad at gcc dot gnu.org ---
The gimple store merging pass performs load/store merging only if the LHS is
memory or constant. I am also working on the GIMPLE pass which will enhance
this to merge other stores as well. Howeve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86209
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
CC||ktkachov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86209
--- Comment #3 from Ramana Radhakrishnan ---
(In reply to sameerad from comment #2)
> Ramana, it is another peephole that I am trying to explore for falkor. It
> combines loads/stores of shorter types (QI/HI/SI) into single load/store of
> larger
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86209
--- Comment #2 from sameerad at gcc dot gnu.org ---
Ramana, it is another peephole that I am trying to explore for falkor. It
combines loads/stores of shorter types (QI/HI/SI) into single load/store of
larger type (SI/DI).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86209
Ramana Radhakrishnan changed:
What|Removed |Added
CC||ramana at gcc dot gnu.org
--- Com
17 matches
Mail list logo
