https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113048
--- Comment #8 from Uroš Bizjak ---
(In reply to Vladimir Makarov from comment #7)
> I believe this PR was recently fixed by
> https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;
> h=a729b6e002fe76208f33fdcdee49d6a310a1940e
Yes, I can confirm that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113255
Uroš Bizjak changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108477
--- Comment #2 from Uroš Bizjak ---
If we consider the following testcase:
--cut here--
unsigned int foo (unsigned int a, unsigned int b)
{
unsigned int r = a & 0x1;
unsigned int p = b & ~0x3;
return r + p + 2;
}
unsigned int bar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108477
--- Comment #1 from Uroš Bizjak ---
This conversion happens due to th following code in match.pd:
/* If we are XORing or adding two BIT_AND_EXPR's, both of which are and'ing
with a constant, and the two constants have no bits in common,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109052
Uroš Bizjak changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113255
--- Comment #3 from Uroš Bizjak ---
_.dse1 pass is removing the store for some reason, -fno-dse "fixes" the
testcase.
Before _.dse1 pass, we have:
(insn 41 40 46 4 (set (mem/c:SI (plus:DI (reg/f:DI 19 frame)
(const_int -36
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113048
Uroš Bizjak changed:
What|Removed |Added
Component|target |rtl-optimization
--- Comment #5 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113231
Uroš Bizjak changed:
What|Removed |Added
CC||roger at nextmovesoftware dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736
Uroš Bizjak changed:
What|Removed |Added
Target Milestone|--- |13.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113133
Uroš Bizjak changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113133
--- Comment #8 from Uroš Bizjak ---
(In reply to Haochen Jiang from comment #6)
> Aha, I see what happened. x/ymm16+ are usable for AVX512F w/o AVX512VL and
> that is why I added that to allow them.
>
> Let me find a way to see if we can fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113133
Uroš Bizjak changed:
What|Removed |Added
CC||haochen.jiang at intel dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113133
Uroš Bizjak changed:
What|Removed |Added
Target Milestone|--- |14.0
--- Comment #3 from Uroš Bizjak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113133
--- Comment #2 from Uroš Bizjak ---
Another testcase:
--cut here--
void
foo1 (double *d, float f)
{
register float x __asm ("xmm16") = f;
asm volatile ("" : "+v" (x));
*d = x;
}
void
foo2 (float *f, double d)
{
register double x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113133
Uroš Bizjak changed:
What|Removed |Added
Last reconfirmed||2023-12-28
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113106
--- Comment #7 from Uroš Bizjak ---
(In reply to Richard Biener from comment #6)
> > BTW: I also checked with clang, and it creates expected code in all cases.
>
> But you don't get
>
>movl%gs:b(%rip), %eax
>addl%eax,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113044
Uroš Bizjak changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113106
--- Comment #5 from Uroš Bizjak ---
The issue in comment #2 happens in a couple of places when compiling linux
kernel (with named address spaces enabled). However, the issue is not specific
to named AS, I was just more attentive to moves from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113106
--- Comment #4 from Uroš Bizjak ---
(In reply to Richard Biener from comment #3)
> The situation with address-spaces isn't valid as we need to preserve the
> second load because it's volatile. I think we simply refuse to combine
> volatile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113044
Uroš Bizjak changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113106
--- Comment #2 from Uroš Bizjak ---
For reference, the same optimization should be applied with address spaces:
--cut here--
int __seg_gs b;
int bar(void)
{
return *(volatile __seg_gs int *) + b;
}
--cut here--
the above testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113106
--- Comment #1 from Uroš Bizjak ---
Perhaps related,
--cut here--
int a;
int foo(void)
{
return *(volatile int *) + *(volatile int *)
}
--cut here--
compiles with -O2 to:
movla(%rip), %eax
movla(%rip), %edx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113106
Bug ID: 113106
Summary: Missing CSE with cast to volatile
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736
--- Comment #7 from Uroš Bizjak ---
(In reply to GCC Commits from comment #5)
> The master branch has been updated by Richard Biener :
Can this patch be backported to gcc-13 branch?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113043
Uroš Bizjak changed:
What|Removed |Added
Component|target |sanitizer
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112962
Uroš Bizjak changed:
What|Removed |Added
Assignee|ubizjak at gmail dot com |unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112962
--- Comment #9 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #8)
> Of course, yet another option is:
This goes out of my (limited) area of expertise, so if my proposed (trivial)
patch is papering over some other issue, I'll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112962
--- Comment #6 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #3)
> I was thinking whether it wouldn't be better to expand x86 const or pure
> builtins when lhs is ignored to nothing in the expanders.
Something like this?
--cut
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112962
--- Comment #4 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #3)
> I was thinking whether it wouldn't be better to expand x86 const or pure
> builtins when lhs is ignored to nothing in the expanders.
Yes, this could be a better
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112962
Uroš Bizjak changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112760
Uroš Bizjak changed:
What|Removed |Added
Component|target |rtl-optimization
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112560
Uroš Bizjak changed:
What|Removed |Added
Keywords||patch
--- Comment #4 from Uroš Bizjak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112560
Uroš Bizjak changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112494
Uroš Bizjak changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112560
Bug 112560 depends on bug 112494, which changed state.
Bug 112494 Summary: ICE in ix86_cc_mode, at config/i386/i386.cc:16477
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112494
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112686
Uroš Bizjak changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112672
Uroš Bizjak changed:
What|Removed |Added
Target Milestone|14.0|11.5
--- Comment #9 from Uroš Bizjak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112686
Uroš Bizjak changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89316
Uroš Bizjak changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112672
Uroš Bizjak changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112445
--- Comment #6 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #4)
> I think this goes wrong during combine.
Combine does not / should not combine moves from hard registers just because of
extending register live range. It looks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112657
--- Comment #6 from Uroš Bizjak ---
This is by design, CMOV should not be used instead of well predicted jumps.
FYI, CMOV is quite problematic on x86, there are several PRs where conversion
to CMOV resulted in 2x slower execution. Please see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112657
--- Comment #5 from Uroš Bizjak ---
Digging a bit further:
if_info.max_seq_cost is calculated via targetm.max_noce_ifcvt_seq_cost, where
without params set we return:
return BRANCH_COST (true, predictable_p) * COSTS_N_INSNS (2);
with:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112657
--- Comment #4 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #3)
> (In reply to Andrew Pinski from comment #2)
>
> > Someone will have to debug ifcvt.cc to see why it fails on x86_64 but works
> > on aarch64. Note there are some
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112657
--- Comment #3 from Uroš Bizjak ---
(In reply to Andrew Pinski from comment #2)
> Someone will have to debug ifcvt.cc to see why it fails on x86_64 but works
> on aarch64. Note there are some new changes to ifcvt.cc in review which
> might
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89316
Uroš Bizjak changed:
What|Removed |Added
Keywords||patch
--- Comment #14 from Uroš Bizjak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89316
Uroš Bizjak changed:
What|Removed |Added
Attachment #56637|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89316
Uroš Bizjak changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111657
--- Comment #9 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #8)
> I'd say it is a user error to invoke memcpy/memset etc. with pointers to
> non-default address spaces, and for aggregate copies the middle-end should
> ensure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112581
--- Comment #3 from Uroš Bizjak ---
(In reply to Andrew Pinski from comment #1)
> It might be one of the x86 specific target patches ...
I don't think so, these patches deal specifically with high registers, and:
$ grep %.h pr112581.s
finds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112567
Uroš Bizjak changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112567
Uroš Bizjak changed:
What|Removed |Added
Last reconfirmed||2023-11-16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112540
Uroš Bizjak changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112540
Uroš Bizjak changed:
What|Removed |Added
Last reconfirmed||2023-11-15
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112494
--- Comment #7 from Uroš Bizjak ---
It looks to me that gcc_unreachable is problematic in SELECT_CC_MODE. We should
simply return CCmode for all unrecognised RTX:
diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.cc
index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112494
--- Comment #6 from Uroš Bizjak ---
Now we have:
#1 0x0286a3aa in try_combine (i3=0x7fffe3c18100, i2=0x7fffe3c18000,
i1=0x0, i0=0x0, new_direct_jump_p=0x7fffd8eb,
last_combined_insn=0x7fffe3c18100) at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112494
--- Comment #5 from Uroš Bizjak ---
Created attachment 56567
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56567=edit
Proposed patch
Nope, even with the above patch the compiler ICEs at the same place:
0x1956968 ix86_cc_mode(rtx_code,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112494
Uroš Bizjak changed:
What|Removed |Added
Component|rtl-optimization|target
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112494
--- Comment #4 from Uroš Bizjak ---
(In reply to Andrew Pinski from comment #3)
> I almost want to say this is a bug in the x86 back-end where it pushes the
> flags onto the stack.
Yes, could be - let me look into this a bit more.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112494
Uroš Bizjak changed:
What|Removed |Added
Last reconfirmed||2023-11-12
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110790
--- Comment #9 from Uroš Bizjak ---
(In reply to Andrew Pinski from comment #8)
> I need some code generation help for gcc.target/i386/pr110790-2.c, I have a
> patch where we now generate:
> ```
> movq(%rdi,%rax,8), %rax
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97503
--- Comment #7 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #6)
> (In reply to LIU Hao from comment #4)
> > Are there any reasons why this was not done for 64?
> > (https://gcc.godbolt.org/z/7vddPdxaP)
>
> There is zero-extension
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97503
--- Comment #6 from Uroš Bizjak ---
(In reply to LIU Hao from comment #4)
> Are there any reasons why this was not done for 64?
> (https://gcc.godbolt.org/z/7vddPdxaP)
There is zero-extension from the result of __builtin_clzll that confuses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112332
Uroš Bizjak changed:
What|Removed |Added
Resolution|--- |FIXED
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112332
--- Comment #3 from Uroš Bizjak ---
diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index 35d073c9a21..75c75f610c2 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -25748,7 +25748,7 @@ (define_peephole2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112332
--- Comment #2 from Uroš Bizjak ---
(In reply to Sergei Trofimovich from comment #1)
> Slightly shorter example:
>
> typedef union {
> double d;
> int L[2];
> } U;
> void d2b(int*);
> void _Py_dg_dtoa(double dd) {
> int be;
> U u;
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110551
--- Comment #7 from Uroš Bizjak ---
(In reply to CVS Commits from comment #5)
> The master branch has been updated by Roger Sayle :
>
> https://gcc.gnu.org/g:89e5d902fc55ad375f149f25a84c516ad360a606
>
> commit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111698
Uroš Bizjak changed:
What|Removed |Added
Target|x86_64-*-* |x86-*-*
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111698
Uroš Bizjak changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736
Bug ID: 111736
Summary: Address sanitizer is not compatible with named address
spaces
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111657
Uroš Bizjak changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111698
--- Comment #2 from Uroš Bizjak ---
(In reply to Richard Biener from comment #1)
> I guess we could do this even on GIMPLE and in general to aligned sub-word
> accesses (where byte accesses are always aligned).
>
> It might be also a good fit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111698
Bug ID: 111698
Summary: Narrow memory access of compare to byte width
Product: gcc
Version: 12.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111657
--- Comment #5 from Uroš Bizjak ---
I have tried to compile with -mtune=nocona that has:
static stringop_algs nocona_memcpy[2] = {
{libcall, {{12, loop_1_byte, false}, {-1, rep_prefix_4_byte, false}}},
{libcall, {{32, loop, false}, {2,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111657
Uroš Bizjak changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111657
Uroš Bizjak changed:
What|Removed |Added
Depends on||79649
--- Comment #1 from Uroš Bizjak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111657
Bug ID: 111657
Summary: Memory copy with structure assignment from named
address space is not working
Product: gcc
Version: 12.3.1
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111340
Uroš Bizjak changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111340
Uroš Bizjak changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65
Uroš Bizjak changed:
What|Removed |Added
CC||hjl.tools at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110762
Uroš Bizjak changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Target Milestone|13.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110832
Uroš Bizjak changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94866
Uroš Bizjak changed:
What|Removed |Added
Target Milestone|--- |14.0
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94866
--- Comment #7 from Uroš Bizjak ---
(In reply to Hongtao.liu from comment #6)
> > So, the compiler still expects vec_concat/vec_select patterns to be present.
>
> v2df foo_v2df (v2df x)
> {
>return __builtin_shuffle (x, (v2df) { 0, 0 },
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111010
Uroš Bizjak changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94866
--- Comment #5 from Uroš Bizjak ---
Created attachment 55778
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55778=edit
Failing patch, for reference
Patch that converts vec_concat/vec_select sse2_movq128 patterns to vec_merge.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94866
--- Comment #4 from Uroš Bizjak ---
(In reply to Hongtao.liu from comment #3)
> in x86 backend expand_vec_perm_1, we always tries vec_merge frist for
> !one_operand_p, expand_vselect_vconcat is only tried when vec_merge failed
> which means we'd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94866
Uroš Bizjak changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111010
Uroš Bizjak changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111010
--- Comment #15 from Uroš Bizjak ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #13)
> > --- Comment #11 from Uroš Bizjak ---
> > Created attachment 55772 [details]
> > -->
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111010
--- Comment #12 from Uroš Bizjak ---
gcc-13 version:
--cut here--
diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index 5363b37d448..df476763f85 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -11527,7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111010
Uroš Bizjak changed:
What|Removed |Added
Attachment #55771|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111010
--- Comment #10 from Uroš Bizjak ---
Created attachment 55771
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55771=edit
Proposed patch
This (untested) patch should solve the PR on trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111010
--- Comment #9 from Uroš Bizjak ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #8)
> > --- Comment #7 from Richard Biener ---
> >
> > diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
> > index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111023
Uroš Bizjak changed:
What|Removed |Added
Assignee|ubizjak at gmail dot com |unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111023
--- Comment #4 from Uroš Bizjak ---
Created attachment 55753
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55753=edit
Proposed patch
Patch that implements zero/sign extend of <= 64byte vector modes to a wider
vector mode also for SSE2.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111023
Uroš Bizjak changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111023
--- Comment #1 from Uroš Bizjak ---
(In reply to Richard Biener from comment #0)
> We could vectorize gcc.dg/vect/pr65947-7.c if we implement the
> extendv4siv4hi pattern (sign-extend V4HI to V4SI). We can already do
> vec_unpacks_lo via
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110991
Uroš Bizjak changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110832
Uroš Bizjak changed:
What|Removed |Added
Last reconfirmed||2023-08-09
101 - 200 of 847 matches
Mail list logo
