https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111657
Uroš Bizjak changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111657
--- Comment #10 from Uroš Bizjak ---
Created attachment 61152
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61152&action=edit
Patch that allows rep_prefix_{1,4,8}_byte algorithms from non-default address
space
Attached patch allows rep_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
Uroš Bizjak changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115568
Uroš Bizjak changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119596
--- Comment #17 from Uroš Bizjak ---
(In reply to Alexander Monakov from comment #16)
> Mateusz, please have a look at PR 95435 for the previous round of tuning for
> AMD, there's a benchmarking script linked from there in PR 43052.
FYI, this b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119539
--- Comment #3 from Uroš Bizjak ---
Comment on attachment 60925
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60925
Untested fix
>+;; Avoid useless masking of count operand.
>+(define_insn_and_split "*3_mask_nf"
>+ [(set (match_operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119450
--- Comment #4 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #3)
> Created attachment 60872 [details]
> gcc15-pr119450.patch
>
> Untested fix.
OK.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
Uroš Bizjak changed:
What|Removed |Added
CC||hjl.tools at gmail dot com,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119357
--- Comment #9 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #7)
[...]
> Or perhaps better just force it into REG:
Just force it into REG. Combine has more freedom this way.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119071
Uroš Bizjak changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119071
--- Comment #13 from Uroš Bizjak ---
(In reply to Sam James from comment #12)
> This works for me on trunk. Did Uros' r15-7793-ga92dc3fe31c95d fix it?
Yes, this is the same issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119083
--- Comment #1 from Uroš Bizjak ---
SSE_FIRST_REG is in ic86_class_likely_spilled_p because it is a single-member
class. It is there because of SSE4 pcmpistrm patterns.
%eax (and other single_class) registers are also listed in
CLASS_LIKELY_SPI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118465
Uroš Bizjak changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118739
--- Comment #17 from Uroš Bizjak ---
V2 patch at [1]:
[1] https://gcc.gnu.org/pipermail/gcc-patches/2025-February/676494.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118994
Uroš Bizjak changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118996
--- Comment #4 from Uroš Bizjak ---
(In reply to Hongtao Liu from comment #1)
> Looking at the hook description, it looks like x86 still need nozero return
> values under apx (due to AREG, DREG, CREG, BREG, SIREG, DIREG)
Please note that we also
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118936
--- Comment #10 from Uroš Bizjak ---
IMO, the original patch that caused ICE is not ready to be committed. HJ, can
you please revert the original patch (+ my dependant patch)?
We will try again for gcc-16.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118936
--- Comment #9 from Uroš Bizjak ---
Also wrong is this part:
+static void
+ix86_find_all_reg_use_1 (rtx set, HARD_REG_SET &stack_slot_access,
+auto_bitmap &worklist)
+{
+ rtx dest = SET_DEST (set);
+ if (!REG_P (dest))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118936
--- Comment #7 from Uroš Bizjak ---
(In reply to H.J. Lu from comment #6)
> This works:
>
> diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.cc
> index 560e6525b56..f5d46296570 100644
> --- a/gcc/config/i386/i386.cc
> +++ b/gcc/confi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118936
--- Comment #5 from Uroš Bizjak ---
For func_40 the new ix86_find_max_used_stack_alignment finds stack_alignment =
256.
The only access with 256 bit alignment in func_40 is:
101: [`g_1679']=xmm0:V2DI
103: [const(`g_1679'+0x10)]=xmm0:V2DI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118936
--- Comment #4 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #3)
> It is due to r15-7575.
Eh, r15-7573.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118936
Uroš Bizjak changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118288
Uroš Bizjak changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118288
Uroš Bizjak changed:
What|Removed |Added
Component|target |middle-end
Assignee|law at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118739
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=118739
--- Comment #15 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #14)
> However (and as shown in Comment #11) the flags register is far from UNUSED
> (let alone DEAD), because it is used in i3. So, the proposed solution is to
> simply
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118739
--- Comment #14 from Uroš Bizjak ---
Untested patch:
--cut here--
diff --git a/gcc/combine.cc b/gcc/combine.cc
index 3beeb514b81..99cd64ada1f 100644
--- a/gcc/combine.cc
+++ b/gcc/combine.cc
@@ -14559,7 +14559,8 @@ distribute_notes (rtx notes,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109780
--- Comment #38 from Uroš Bizjak ---
(In reply to Sam James from comment #29)
> $ gcc-14 p.c -o p -O2 -march=znver1 -fno-stack-protector
> -fno-stack-clash-protection && ./p
> Segmentation fault (core dumped)
Adding -mpreferred-stack-boundary=3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109780
--- Comment #37 from Uroš Bizjak ---
(In reply to H.J. Lu from comment #23)
> Created attachment 55424 [details]
> An updated patch
Is this patch similar to the one in PR109093#c17 ? As argued in PR109093#c35,
it looks that the current detectio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109093
--- Comment #35 from Uroš Bizjak ---
(In reply to H.J. Lu from comment #17)
> Created attachment 54666 [details]
> A patch
>
> Change ix86_find_max_used_stack_alignment to find alignments of all stack
> slot accesses.
HJ, it looks that the cur
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109780
--- Comment #36 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #35)
> It is not a good idea to CSE address that refers to virtual stack vars to a
> temporary. This defeats stack/frame pointer detection, mentioned in Comment
> #33, a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109780
--- Comment #35 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #34)
> The problematic code is expanded from:
>
> ;; Generating RTL for gimple basic block 5
>
> ;; __builtin_memset (&k, 0, 40);
>
> (insn 21 20 22 (parallel [
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109780
--- Comment #34 from Uroš Bizjak ---
The problematic code is expanded from:
;; Generating RTL for gimple basic block 5
;; __builtin_memset (&k, 0, 40);
(insn 21 20 22 (parallel [
(set (reg:DI 107)
(plus:DI (reg/f:D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109780
--- Comment #33 from Uroš Bizjak ---
FTR, ix86_find_max_used_stack_alignment increases alignment only when stack
pointer or frame pointer are explicitly mentioned in :
/* Find the maximum stack alignment. */
sub
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115568
--- Comment #9 from Uroš Bizjak ---
The asm dump from Comment #6 now looks correct:
movl%edi, %r14d # 122 [c=4 l=3] *movsi_internal/0
movl%r14d, -44(%rsp)# 476 [c=4 l=5] *movsi_internal/1
-> movl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118739
--- Comment #11 from Uroš Bizjak ---
Oh, we have this issue:
Trying 16, 22, 21 -> 23:
16: r106:QI=flags:CCNO>0
22: {r120:QI=r106:QI^0x1;clobber flags:CC;}
REG_UNUSED flags:CC
21: r119:QI=flags:CCNO<=0
REG_DEAD flags:CCNO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118739
--- Comment #12 from Uroš Bizjak ---
(In reply to Sam James from comment #10)
> r15-268-g9dbff9c05520a7
This commit just prevents the transformation in Comment #11 from happening,
because it skips an early combination of:
Trying 15 -> 16:
1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118739
--- Comment #9 from Uroš Bizjak ---
(In reply to Andrew Pinski from comment #7)
> So r115's value will be 0 or 1 (STORE_FLAG_VALUE) so (gt:QI r115 0) is the
> same as (subreg:QI r115). Unless I am missing something here.
No, you are right. Tak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118739
Uroš Bizjak changed:
What|Removed |Added
Component|target |rtl-optimization
--- Comment #6 from Uroš
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118739
--- Comment #5 from Uroš Bizjak ---
So, we have:
Trying 15 -> 16:
15: flags:CCNO=cmp(r115:SI,0)
REG_DEAD r115:SI
16: r106:QI=flags:CCNO>0
Successfully matched this instruction:
(set (reg:CCNO 17 flags)
(compare:CCNO (reg:SI 115
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118739
--- Comment #4 from Uroš Bizjak ---
This is the difference I get:
--- pass/pr118739.s 2025-02-04 11:08:20.003694978 +0100
+++ fail/pr118739.s 2025-02-04 11:08:32.943651165 +0100
@@ -21,16 +21,11 @@
.cfi_offset 3, -32
mov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115673
--- Comment #23 from Uroš Bizjak ---
Comment on attachment 60337
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60337
A patch with tests
>@@ -10225,13 +10225,15 @@ ix86_expand_call (rtx retval, rtx fnaddr, rtx
>callarg1,
> fnaddr = g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115673
--- Comment #22 from Uroš Bizjak ---
Comment on attachment 60337
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60337
A patch with tests
>From 1503e1e1df7a402d4be560fdc446dd6c39127e9c Mon Sep 17 00:00:00 2001
>From: "H.J. Lu"
>Date: Fri,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115673
--- Comment #19 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #18)
> Created attachment 60331 [details]
> Prototype patch
>
> Prototype patch that disables constraints, unwanted with
> flag_force_indirect_call.
HJ, can you please
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115673
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=118662
--- Comment #15 from Uroš Bizjak ---
The testcase now generates (-O2 -ftree-slp-vectorize -fno-vect-cost-model
-msse4):
addup:
pmovsxbd(%rdi), %xmm0
movd(%rdi), %xmm1
movdqa %xmm0, %xmm2
pextrb $3,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118662
--- Comment #16 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #15)
> One possible improvement would be to move QImode value to %xmm1 and
V4QImode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118662
Uroš Bizjak changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
Compon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118662
--- Comment #10 from Uroš Bizjak ---
Before combine pass we have (_.297r.ud_dce):
(insn 7 4 9 2 (set (reg:V4QI 106 [ MEM [(type1
*)num_13(D)] ])
(mem:V4QI (reg/v/f:DI 105 [ num ]) [0 MEM
[(type1 *)num_13(D)]+0 S4 A8])) "pr118662.c":9:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118638
Uroš Bizjak changed:
What|Removed |Added
CC||law at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118638
--- Comment #8 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #7)
This one is wrong:
> Trying 11, 12 -> 16:
>11: r109:SI=flags:CCZ!=0
> REG_DEAD flags:CCZ
>12: r109:SI=r109:SI*0x2+r109:SI
>16: {r111:SI=sign_extract
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118638
--- Comment #7 from Uroš Bizjak ---
(In reply to Sam James from comment #5)
> I think it's going to be r14-4810-ge28869670c9879.
There is nothing wrong with the splitter from the above commit, but the pattern
enables quite some creative combina
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115568
Uroš Bizjak changed:
What|Removed |Added
Keywords||ra
--- Comment #6 from Uroš Bizjak ---
I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118067
--- Comment #19 from Uroš Bizjak ---
(In reply to Eric Botcazou from comment #18)
> The latest change made for this PR has introduced a number of regressions on
> the SPARC of the form:
FAOD, the referred "latest change" is:
commit r15-6968-gd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118067
Uroš Bizjak changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118067
--- Comment #10 from Uroš Bizjak ---
Please note that RA loops with SImode, the dump from _.324r.reload reads:
(insn 193 5 191 2 (set (reg:SI 338)
(subreg/j:SI (reg/v:V32HI 165 [ u ]) 0)) "pr118067.c":13:8 96
{*movsi_internal}
(nil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118067
--- Comment #9 from Uroš Bizjak ---
Unfortunately, the testcase still fails when -mtune=k8 is added to compile
flags:
gcc -O -fno-split-wide-types -mavx512f -mtune=k8
in the same way as reported in Comment #5. The asm dump without -mtune=k8
(g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118510
--- Comment #2 from Uroš Bizjak ---
Something like the following patch should fix the ICE:
--cut here--
diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index 362b0ddcf40..2f1997bc36c 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118510
Uroš Bizjak changed:
What|Removed |Added
Last reconfirmed||2025-01-16
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118067
--- Comment #6 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #5)
> The problematic insn is still:
>
> (insn 9 5 10 2 (parallel [
> (set (reg:HI 99 [ _2 ])
> (lshiftrt:HI (subreg:HI (reg/v:V32HI 165 [ u ]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118067
--- Comment #5 from Uroš Bizjak ---
The problematic insn is still:
(insn 9 5 10 2 (parallel [
(set (reg:HI 99 [ _2 ])
(lshiftrt:HI (subreg:HI (reg/v:V32HI 165 [ u ]) 0)
(const_int 1 [0x1])))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118067
--- Comment #4 from Uroš Bizjak ---
Still fails, even with the fix for PR118017 applied. Thus, not a duplicate of
PR118017.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118017
Uroš Bizjak changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118042
Uroš Bizjak changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118342
--- Comment #11 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #10)
> Guess the first question is if we want to change this for GCC 15 or if that
> is too late for that.
I think this is just tricky enough to leave it for GCC 16.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118342
--- Comment #9 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #8)
> Now, at the RTL level, for SImode it could certainly be
> (set (match_operand:SI 0 "register_operand "=r")
> (if_then_else:SI (match_operand:SI 1 "register_op
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118342
--- Comment #7 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #6)
> Yes, so we can use it for a == 0 ? prec : __builtin_ctzll (a); but not say
> (with small middle-end enhancements) for a == 0 ? -1 : __builtin_ctzll (a);
> because
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118333
Uroš Bizjak changed:
What|Removed |Added
CC||liuhongt at gcc dot gnu.org
Ever conf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118017
Uroš Bizjak changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118067
--- Comment #2 from Uroš Bizjak ---
Created attachment 59935
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59935&action=edit
Target-dependant patch
SImode and DImode moves involving mask registers are valid only with AVX512BW,
so mark re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118067
Uroš Bizjak changed:
What|Removed |Added
Component|target |rtl-optimization
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118042
Uroš Bizjak changed:
What|Removed |Added
Status|ASSIGNED|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118042
Uroš Bizjak changed:
What|Removed |Added
Component|target |rtl-optimization
Assignee|ubizj
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118042
--- Comment #4 from Uroš Bizjak ---
Comment on attachment 59875
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59875
Proposed patch
>diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.cc
>index ca763e1eb33..530e7e4fb54 100644
>--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118017
--- Comment #7 from Uroš Bizjak ---
(In reply to Hongtao Liu from comment #6)
> (In reply to Uroš Bizjak from comment #5)
> > (In reply to Uroš Bizjak from comment #4)
> >
> > > Please note that TImode and TDmode are tieable on x86_64 targets,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118042
Uroš Bizjak changed:
What|Removed |Added
Component|rtl-optimization|target
--- Comment #3 from Uroš Bizjak -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118042
Uroš Bizjak changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118017
Uroš Bizjak changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118017
--- Comment #4 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #3)
> It looks to me that reload is trying to handle the following sequence from
> _.322r.ira dump:
>
> (insn 32 31 35 2 (set (subreg:TI (reg:TD 99 [ _2 ]) 0)
> (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118017
--- Comment #3 from Uroš Bizjak ---
It looks to me that reload is trying to handle the following sequence from
_.322r.ira dump:
(insn 32 31 35 2 (set (subreg:TI (reg:TD 99 [ _2 ]) 0)
(reg:TI 20 xmm0)) "pr118017.c":14:24 94 {*movti_inter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116979
--- Comment #18 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #17)
> Not marking as fixed for GCC 15 yet, as there is the scalar cost computation
> issue unresolved.
There is also a issue how the final result for SFmode is constru
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44574
--- Comment #16 from Uroš Bizjak ---
(In reply to Heiko Eißfeldt from comment #12)
> (In reply to GCC Commits from comment #11)
> > The trunk branch has been updated by Andrew Pinski :
> ...
> > Note since this code
> > still uses atoi, an in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116979
--- Comment #14 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #12)
> With the following patch instead it isn't vectorized anymore and uses scalar
> code:
AFAICS, this is the correct patch to implement partial vector V2SFmode patte
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117946
Uroš Bizjak changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117938
--- Comment #13 from Uroš Bizjak ---
(In reply to Andrew Pinski from comment #12)
> so just the insn #s are different; oh because I accidently was using -g.
> Anyways what I said still applies here too.
Indeed, there is (insn 338) all the way d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117938
--- Comment #11 from Uroš Bizjak ---
Created attachment 59822
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59822&action=edit
.postreload and .late_combine2 dumps
pr117938.c.323r.postreload
pr117938.c.325r.late_combine2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117938
--- Comment #8 from Uroš Bizjak ---
(In reply to Andrew Pinski from comment #7)
> It is the moving insn that is the issue.
Please see _.325r.late_combine2 dump, there are *two* equal instructions (as
reported in Comment #5). The compiler is not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117938
--- Comment #6 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #5)
> but in _.325r.late_combine dump, the same sequence got additional (insn 338)
_.325r.late_combine2 dump, ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117938
Uroš Bizjak changed:
What|Removed |Added
CC||ubizjak at gmail dot com
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117938
--- Comment #4 from Uroš Bizjak ---
The return from foo() with -flate-combine-instructions has one bit difference:
$2 = {0x7fff7fff, 0x,
0x, 0xf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117938
--- Comment #3 from Uroš Bizjak ---
(In reply to Andrew Pinski from comment #2)
> I don't see anything that late combine would do that would be wrong.
Adding -fno-late-combine-instructions to compile flags avoids abort.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117946
Uroš Bizjak changed:
What|Removed |Added
Component|target |rtl-optimization
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117930
--- Comment #2 from Uroš Bizjak ---
Comment on attachment 59799
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59799
gcc15-pr117930.patch
>+;; Other rotate.
>+(define_code_attr orotate [(rotate "rotatert") (rotatert "rotate")])
Can we us
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117926
Uroš Bizjak changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117926
--- Comment #7 from Uroš Bizjak ---
Even better (and more reliable) solution: tag 3dNOW insns with an unspec:
(define_insn "mmx_floatv2siv2sf2"
[(set (match_operand:V2SF 0 "register_operand" "=y")
- (float:V2SF (match_operand:V2SI 1 "
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117926
--- Comment #6 from Uroš Bizjak ---
We have to prevent forward propagation by disabling memory operand for
!TARGET_MMX_WITH_SSE:
(define_insn "mmx_floatv2siv2sf2"
- [(set (match_operand:V2SF 0 "register_operand" "=y")
- (float:V2SF (mat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117860
Uroš Bizjak changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117860
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=117860
--- Comment #2 from Uroš Bizjak ---
(In reply to Andrew Pinski from comment #1)
> Confirmed.
>
> I think it should be easy to support it with a slight change to this pattern:
> ```
> (define_insn "addcarry"
> [(set (reg:CCC FLAGS_REG)
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117105
Uroš Bizjak changed:
What|Removed |Added
Target Milestone|15.0|14.3
1 - 100 of 1077 matches
Mail list logo
