On 1/24/25 3:57 AM, Robin Dapp wrote:
So this isn't a regression, but I can also understand the desire to fix
this fairly significant performance issue.
I'd argue it is a regression as the match.pd pattern that merges the permutes
was introduces after GCC 14.
Good point. I hadn't thought ab
> So this isn't a regression, but I can also understand the desire to fix
> this fairly significant performance issue.
I'd argue it is a regression as the match.pd pattern that merges the permutes
was introduces after GCC 14.
After giving it a bit more thought, I'd still like to send the attache
On 1/22/25 12:29 AM, Robin Dapp wrote:
Hi,
after testing on the BPI (4.2% improvement for x264 input 1, 4.4% for input 2)
and the discussion in PR117173 I figured it's best to disable the two-source
permutes by default for now. We quickly talked about this on the patchwork
call last week. C
lgtm.
--Reply to Message--
On Wed, Jan 22, 2025 16:04 PM Robin Dapp
> Could you show me the a piece of codegen difference in X264 that make
> performance improved ?
I have one ready from SATD (see PR117173), there are more.
"Before":
_838 = VEC_PERM_EXPR ;
_846 = VEC_PERM_EXPR ;
"After":
_42 = VEC_PERM_EXPR ;
...
_44 = VEC_PERM_EXPR ;
_45 = VEC_PERM_EXPR ;
"A
@gmail.com
Subject: [PATCH] RISC-V: Disable two-source permutes for now [PR117173].
Hi,
after testing on the BPI (4.2% improvement for x264 input 1, 4.4% for input 2)
and the discussion in PR117173 I figured it's best to disable the two-source
permutes by default for now. We quickly talked
Hi,
after testing on the BPI (4.2% improvement for x264 input 1, 4.4% for input 2)
and the discussion in PR117173 I figured it's best to disable the two-source
permutes by default for now. We quickly talked about this on the patchwork
call last week. Conclusion was to just post the patch and dis
