On 6/6/23 00:47, Richard Biener wrote:
I wonder if there's some more generic target macro we can key the
behavior off - SLOW_BYTE_ACCESS isn't a good fit, WORD_REGISTER_OPERATIONS
is maybe closer but it's exact implications are unknown to me. Maybe
there's something else as well ...
LOAD_EX
On Mon, Jun 5, 2023 at 8:41 PM Jeff Law wrote:
>
>
>
> On 6/5/23 00:29, Richard Biener wrote:
>
> >
> > But then for example x86 has smaller encoding for byte ops and while
> > widening is easily done later, truncation is not.
> Sadly, the x86 costing looks totally bogus here. We actually emit th
On 6/5/23 00:29, Richard Biener wrote:
But then for example x86 has smaller encoding for byte ops and while
widening is easily done later, truncation is not.
Sadly, the x86 costing looks totally bogus here. We actually emit the
exact same code for a QI mode loads vs a zero-extending load f
On 6/5/23 00:29, Richard Biener wrote:
But then for example x86 has smaller encoding for byte ops and while
widening is easily done later, truncation is not.
Which probably argues we need to be checking costs.
Btw, you failed to update the overall function comment which lists
the convers
On Sun, Jun 4, 2023 at 11:41 PM Jeff Law via Gcc-patches
wrote:
>
> While investigating a RISC-V backend patch from Jivan I noticed a
> regression in terms of dynamic instruction counts for the omnetpp
> benchmark in spec2017.
>
> https://gcc.gnu.org/pipermail/gcc-patches/2023-June/620577.html
>
>
While investigating a RISC-V backend patch from Jivan I noticed a
regression in terms of dynamic instruction counts for the omnetpp
benchmark in spec2017.
https://gcc.gnu.org/pipermail/gcc-patches/2023-June/620577.html
The code we we with Jivan's patch at expansion time looks like this for
ea
