https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114591
--- Comment #13 from Uroš Bizjak ---
(In reply to Hongtao Liu from comment #12)
> short a;
> short c;
> short d;
> void
> foo (short b, short f)
> {
> c = b + a;
> d = f + a;
> }
>
> foo(short, short):
> addwa(%rip), %di
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112560
--- Comment #13 from Uroš Bizjak ---
(In reply to Segher Boessenkool from comment #12)
> You cannot use a :CC value as argument of an unspec, as explained before.
>
> The result of a comparison is expressed as a comparison, in RTL. This patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112560
--- Comment #11 from Uroš Bizjak ---
(In reply to Segher Boessenkool from comment #10)
> It is still wrong. You're trying to sweep tour wrong assumptions under the
> rug,
> but they will only rear up elsewhere. Just fix the actual *target*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114591
--- Comment #10 from Uroš Bizjak ---
(In reply to Hongtao Liu from comment #5)
> > My experience is memory cost for the operand with rm or separate r, m is
> > different which impacts RA decision.
> >
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114591
--- Comment #8 from Uroš Bizjak ---
BTW: The reason for the original change:
(define_insn "*movhi_internal"
- [(set (match_operand:HI 0 "nonimmediate_operand" "=r,r ,r ,m ,*k,*k
,*r,*m,*k,?r,?v,*v,*v,*m")
- (match_operand:HI 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114591
--- Comment #7 from Uroš Bizjak ---
(In reply to Hongtao Liu from comment #5)
> > My experience is memory cost for the operand with rm or separate r, m is
> > different which impacts RA decision.
> >
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114591
--- Comment #6 from Uroš Bizjak ---
LRA starts with this:
5: r98:SI=[`v1']
REG_EQUIV [`v1']
6: [`v2']=zero_extend(r98:SI)
7: r101:HI=r98:SI#0
REG_DEAD r98:SI
12: ax:HI=r101:HI
REG_DEAD r101:HI
13: use ax:HI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114591
--- Comment #3 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #2)
> This changed with r12-5584-gca5667e867252db3c8642ee90f55427149cd92b6
Strange, if I revert the constraints to the previous setting with:
--cut here--
diff --git
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112560
--- Comment #9 from Uroš Bizjak ---
(In reply to Richard Biener from comment #8)
> Fixed I suppose.
Yes - I plan backport the patch to at least gcc-13.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114639
--- Comment #9 from Uroš Bizjak ---
(In reply to Andrew Pinski from comment #2)
> /* If we didn't see a full return value copy, verify that there
>is a plausible reason for this. If some, but not all of the
>
||ubizjak at gmail dot com
Last reconfirmed||2024-04-02
Status|UNCONFIRMED |NEW
--- Comment #3 from Uroš Bizjak ---
The similar testcase with comparison to zero:
int z(int *v, int n) {
*v -= n;
return *v == 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114487
--- Comment #4 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #3)
> (In reply to Uroš Bizjak from comment #2)
> > Adding -msse to the second compilation works OK, removing -mfpmath=sse from
> > the first compilation also works OK.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114487
--- Comment #3 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #2)
> Adding -msse to the second compilation works OK, removing -mfpmath=sse from
> the first compilation also works OK.
Which makes this PR a LTO reincarnation of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114487
--- Comment #2 from Uroš Bizjak ---
(In reply to Richard Biener from comment #1)
> (insn 6 5 0 (set (reg/v:SF 99 [ gamma ])
> (reg:SF 20 xmm0)) "testautomation-testautomation_pixels.i":15:17 -1
> (nil))
>
> I'm not sure what's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736
--- Comment #29 from Uroš Bizjak ---
Do we also need to adjust TSAN? There is a bugreport that KCSAN does work
correctly with the named address spaces.(In reply to Jakub Jelinek from comment
#28)
> Created attachment 57807 [details]
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736
--- Comment #26 from Uroš Bizjak ---
Do we also need to adjust TSAN? There is a bugreport that KCSAN does work
correctly with the named address spaces.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736
--- Comment #19 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #16)
> (In reply to Richard Biener from comment #13)
> > The original testcase is fixed, appearantly slapping 'extern' on the int
> > makes it not effective.
> >
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736
--- Comment #16 from Uroš Bizjak ---
(In reply to Richard Biener from comment #13)
> The original testcase is fixed, appearantly slapping 'extern' on the int
> makes it not effective.
>
> Possibly better amend the
>
> if (VAR_P (inner) &&
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736
Uroš Bizjak changed:
What|Removed |Added
Priority|P3 |P1
--- Comment #12 from Uroš Bizjak ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736
--- Comment #11 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #10)
> Huh, is this really fixed?
IMO, this patch is also needed:
--cut here--
diff --git a/gcc/asan.cc b/gcc/asan.cc
index cfe83106460..54dcc3a38db 100644
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736
Uroš Bizjak changed:
What|Removed |Added
Resolution|FIXED |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111822
--- Comment #22 from Uroš Bizjak ---
Fixed also for TImode STV.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111822
--- Comment #18 from Uroš Bizjak ---
When we split
(insn 37 36 38 10 (set (reg:DI 104 [ _18 ])
(mem:DI (reg/f:SI 98 [ CallNative_nclosure.0_1 ]) [6 MEM[(struct
SQRefCounted *)CallNative_nclosure.0_1]._uiRef+0 S8 A32])) "test.C":22:42 84
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40130
Uroš Bizjak changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112560
--- Comment #6 from Uroš Bizjak ---
v3 patch at [1]
[1] https://gcc.gnu.org/pipermail/gcc-patches/2024-March/647634.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112560
Uroš Bizjak changed:
What|Removed |Added
Attachment #56705|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111822
--- Comment #13 from Uroš Bizjak ---
(In reply to Richard Biener from comment #12)
> > But I think, we could do better. Adding CC.
>
> We sure could, but I doubt it's too important? Maybe for Go/Ada.
Preloading stuff is simply loading from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111822
Uroš Bizjak changed:
What|Removed |Added
CC||liuhongt at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111822
--- Comment #9 from Uroš Bizjak ---
The offending insn is emitted in general_scalar_chain::convert_op due to
preloading, but I have no idea how EH should be adjusted. There is another
instance in timode_scalar_chain::convert_op.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114232
Uroš Bizjak changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114232
Uroš Bizjak changed:
What|Removed |Added
Attachment #57614|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114232
--- Comment #25 from Uroš Bizjak ---
Created attachment 57614
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57614=edit
Proposed patch
Proposed patch that changes optimize_function_for_size_p (cfun) to
optimize_size.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114232
--- Comment #23 from Uroš Bizjak ---
(In reply to Jan Hubicka from comment #21)
> Looking at the prototype patch, why need to change also the splitters?
Purely for implementation reasons, we check for general resp. SSE register in
the operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114232
--- Comment #19 from Uroš Bizjak ---
(In reply to Jan Hubicka from comment #18)
> But the problem here is more that optab initializations happens only at
> the optimization_node changes and not if we switch from hot function to
> cold?
I think
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114232
--- Comment #16 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #15)
> Seems various backends use e.g. optimize_size or !optimize_size or optimize
> > 0 etc. in
> insn-flags.h, so perhaps change optimize_function_for_size_p (cfun)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114211
--- Comment #9 from Uroš Bizjak ---
Noticed this in passing:
--> movq%rcx, %rdx
addqv(%rip), %rax
adcqv+8(%rip), %rdx
vmovq %rax, %xmm1
vpinsrq $1, %rdx, %xmm1, %xmm0
We could use %rcx instead
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114232
--- Comment #13 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #12)
> Still, it would be nice to understand what changed
> optimize_function_for_size_p (cfun)
> after IPA. Is something adjusting node->count or node->frequency?
>
at gcc dot gnu.org |ubizjak at gmail dot com
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0 |1
--- Comment #10 from Uroš Bizjak ---
Created attachment 57612
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57612=edit
Protot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114232
--- Comment #9 from Uroš Bizjak ---
(In reply to Richard Biener from comment #8)
> > grep optimize_ insn-flags.h | wc -l
> 14
>
> so it's not very many standard patterns that would be affected. I'd say
> using these kind of flags on standard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114232
--- Comment #5 from Uroš Bizjak ---
Huh, it looks that optimize_function_for_size_p (cfun) is not stable during
LTO?!
Using:
--cut here--
diff --git a/gcc/config/i386/mmx.md b/gcc/config/i386/mmx.md
index 2856ae6ffef..80114494b0b 100644
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114232
--- Comment #4 from Uroš Bizjak ---
(In reply to Sam James from comment #0)
> (insn 160 159 161 26 (parallel [
> (set (reg:V2QI 250 [ vect_patt_207.470_183 ])
> (minus:V2QI (reg:V2QI 251)
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114211
Uroš Bizjak changed:
What|Removed |Added
Component|target |rtl-optimization
at gcc dot gnu.org |ubizjak at gmail dot com
Status|NEW |RESOLVED
--- Comment #8 from Uroš Bizjak ---
Assuming fixed, please reopen if not.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113576
--- Comment #56 from Uroš Bizjak ---
The testcase is fixed with g:430c772be3382134886db33133ed466c02efc71c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113871
Uroš Bizjak changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113576
--- Comment #55 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #53)
> Comment on attachment 57424 [details]
> Proposed testsuite patch
>
> As skylake-avx512 is -mavx512{f,cd,bw,dq,vl}, requiring just avx512f
> effective target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113576
--- Comment #52 from Uroš Bizjak ---
Created attachment 57424
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57424=edit
Proposed testsuite patch
This patch fixes the failure for me (+ some other dg.exp/vect inconsistencies).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113576
--- Comment #48 from Uroš Bizjak ---
The runtime testcase fails on non-AVX512F x86 targets due to:
/* { dg-do run } */
/* { dg-options "-O3" } */
/* { dg-additional-options "-march=skylake-avx512" { target { x86_64-*-*
i?86-*-* } } } */
but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113871
Uroš Bizjak changed:
What|Removed |Added
Attachment #57417|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113871
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=113720
--- Comment #5 from Uroš Bizjak ---
(In reply to Matthias Klose from comment #4)
> Uros proposed patch lets the build succeed.
FTR, the problem was in umuldi3_highpart expander, which did:
if (REG_P (operands[2]))
operands[2] =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113720
--- Comment #1 from Uroš Bizjak ---
Created attachment 57292
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57292=edit
Patch that introduces umul_highpart RTX
Please try the attached (untested) patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82580
Uroš Bizjak changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113701
--- Comment #4 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #2)
> > The most problematic function is f3, which regressed noticeably from
> > gcc-12.3:
>
> This patch solves the regression:
>
> --cut here--
> diff --git
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113701
--- Comment #2 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #0)
> Following testcase:
>
> --cut here--
> typedef unsigned __int128 U;
>
> U f0 (U x, U y) { return x + y; }
> U f1 (U x, U y) { return x - y; }
>
> U f2 (U x, U y)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113701
Uroš Bizjak changed:
What|Removed |Added
CC||roger at nextmovesoftware dot
com
---
Assignee: unassigned at gcc dot gnu.org
Reporter: ubizjak at gmail dot com
Target Milestone: ---
Following testcase:
--cut here--
typedef unsigned __int128 U;
U f0 (U x, U y) { return x + y; }
U f1 (U x, U y) { return x - y; }
U f2 (U x, U y) { return x | y; }
int f3 (U x, U
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113609
--- Comment #2 from Uroš Bizjak ---
(In reply to Hongtao Liu from comment #1)
> Since they're different modes, CCZ for cmp, but CCS for kortest, it could be
> diffcult to optimize it in RA stage by adding alternatives(like we did for
> compared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82580
Uroš Bizjak changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45434
--- Comment #9 from Uroš Bizjak ---
The current mainline compiles:
--cut here--
_Bool foo(int i)
{
return (i & 0xFF) == ((i & 0xFF00) >> 8);
}
_Bool bar(int i)
{
return (i & 0xFF) <= ((i & 0xFF00) >> 8);
}
--cut here--
with -O2 to:
foo:
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
|UNCONFIRMED |ASSIGNED
Ever confirmed|0 |1
Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com
--- Comment #1 from Uroš Bizjak ---
Created attachment 56962
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56962=edit
Propo
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
Assignee: unassigned at gcc dot gnu.org
Reporter: ubizjak at gmail dot com
Target Milestone: ---
The following testcase:
--cut here--
int a;
int foo(void)
{
return *(volatile int *) + a;
}
--cut here--
compiles with -O2 to:
movla(%rip), %eax
addla(%rip
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|---
at gcc dot gnu.org |ubizjak at gmail dot com
--- Comment #4 from Uroš Bizjak ---
(In reply to Andrew Pinski from comment #3)
> parityhi2 should have:
> rtx extra = gen_reg_rtx (HImode);
> emit_move_insn (extra, operands[1]);
> emit_insn (gen_parityhi2_cmp (extra));
>
> Or
1 - 100 of 6562 matches
Mail list logo
