https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100182
--- Comment #17 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #16)
> (In reply to Jakub Jelinek from comment #15)
> > Yes, but do they preserve all the bits and never modify any bit patterns,
> > including qNaNs and sNaNs? I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100182
--- Comment #16 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #15)
> Yes, but do they preserve all the bits and never modify any bit patterns,
> including qNaNs and sNaNs? I thought the point of using the fistp was that
> it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100182
--- Comment #14 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #13)
> DFmode loads and stores *are* atomic, this is what the optimization is based
> on.
Loads and stores to/from x87 and SSE registers, to be clear.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100182
--- Comment #13 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #12)
> They do. Though, in the combined patch I'm still a little bit worried about
> the first 4 modified peephole2s, the last 4 look good to me.
> The last 4 are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100182
--- Comment #11 from Uroš Bizjak ---
Jakub, do these two patches fix your failures?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100182
--- Comment #10 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #9)
> (In reply to Jakub Jelinek from comment #8)
> > I think there are 8 those peephole2s rather than just 4 (I've been looking
> > for
> > rtx_equal_p (XEXP.*, 0) in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100182
--- Comment #9 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #8)
> I think there are 8 those peephole2s rather than just 4 (I've been looking
> for
> rtx_equal_p (XEXP.*, 0) in sync.md
No, the other are not problematic.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100182
Uroš Bizjak changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|uros at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100119
--- Comment #2 from Uroš Bizjak ---
diff --git a/gcc/config/i386/i386-expand.c b/gcc/config/i386/i386-expand.c
index dda08ff67f2..5a7a00c13bd 100644
--- a/gcc/config/i386/i386-expand.c
+++ b/gcc/config/i386/i386-expand.c
@@ -1550,6 +1550,8 @@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100041
Uroš Bizjak changed:
What|Removed |Added
Target Milestone|11.0|12.0
--- Comment #20 from Uroš Bizjak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100041
--- Comment #18 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #17)
> Can we go with #c15 for GCC11 and do #c16 for GCC12?
I'd like to kill the option for GCC11, and the solution is safer than #c15.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100041
Uroš Bizjak changed:
What|Removed |Added
Target|x86_64-linux-musl |x86_64
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100041
Uroš Bizjak changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100041
--- Comment #15 from Uroš Bizjak ---
(In reply to Richard Biener from comment #12)
> A possible solution might be to disallow the -m64 -m96bit-long-double
> combination, the documentation suggests -m128bit-long-double was intended
> as an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100041
--- Comment #13 from Uroš Bizjak ---
See PR79514.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100021
--- Comment #2 from Uroš Bizjak ---
Also, you are passing -march=sandybridge, but the profiler seems to show
Skylake (SKX) target. The STV pass heavily depends on target costs, and when
-march=skylake is passed, the conversion is avoided.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100021
--- Comment #1 from Uroš Bizjak ---
This is not vectorization, but the compiler uses vector registers to perform
scalar operations. This is STV (scalar-to-vector) pass in action, you can use
-mno-stv to avoid transformation.
The transformation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99930
--- Comment #6 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #4)
> Is there some reason why the patterns are written that way rather than split
> immediately into the AND or XOR? Perhaps it could be done on SUBREGs to
> make it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99652
--- Comment #5 from Uroš Bizjak ---
inline long double
foo (void)
{
return 1.0;
}
gcc -S -O2 -mno-80387 double.c
double.c: In function ‘foo’:
double.c:3:1: error: x87 register return with x87 disabled
3 | {
| ^
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99601
--- Comment #3 from Uroš Bizjak ---
(In reply to CVS Commits from comment #1)
> The master branch has been updated by Nathan Sidwell :
>
> https://gcc.gnu.org/g:770d3487ef18a71f65626c182625889eee29f580
There is a typo in the selector:
+// {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98856
--- Comment #34 from Uroš Bizjak ---
(In reply to rguent...@suse.de from comment #32)
> what about reload_completed? We really only want to do this after RA.
No need for it, this is peephole2 pass that *always* runs after reload.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99405
--- Comment #2 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #1)
> Created attachment 50306 [details]
> gcc11-pr99405.patch
>
> Untested fix.
- (match_operand:SI 2 "register_operand" "c")
+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98856
--- Comment #31 from Uroš Bizjak ---
(In reply to Richard Biener from comment #29)
> The simplified variant below works but IMHO matches cases we do not
> want to transform. I can't find any example on how to achieve that
> though.
I think
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98856
--- Comment #28 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #27)
> (In reply to Richard Biener from comment #26)
> > but that doesn't seem to match for some unknown reason.
> Try this:
The latency problem with the original
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98856
--- Comment #27 from Uroš Bizjak ---
(In reply to Richard Biener from comment #26)
> but that doesn't seem to match for some unknown reason.
Try this:
(define_peephole2
[(match_scratch:DI 5 "Yv")
(set (match_operand:DI 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98856
--- Comment #24 from Uroš Bizjak ---
(In reply to Richard Biener from comment #22)
> That works to avoid the vpinsrq. I guess the case of a mem operand
> behaves similar to a gpr (plus the load uop), at least I don't have any
> contrary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98856
--- Comment #21 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #20)
> (In reply to Richard Biener from comment #18)
> > Even on Skylake it's 2 (movq) + 3 (vpinsr), so there it's 6 vs. 3. Not
> > sure if we should somehow do this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98856
--- Comment #20 from Uroš Bizjak ---
(In reply to Richard Biener from comment #18)
> Even on Skylake it's 2 (movq) + 3 (vpinsr), so there it's 6 vs. 3. Not
> sure if we should somehow do this late somehow (peephole or splitter) since
> it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 99083, which changed state.
Bug 99083 Summary: Big run-time regressions of 519.lbm_r with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99083
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99083
Uroš Bizjak changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 99083, which changed state.
Bug 99083 Summary: Big run-time regressions of 519.lbm_r with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99083
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99083
Uroš Bizjak changed:
What|Removed |Added
Target Milestone|--- |11.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99083
Uroš Bizjak changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99115
--- Comment #4 from Uroš Bizjak ---
Compiles OK with:
GNU C++14 (GCC) version 8.4.1 20210216 [releases/gcc-8 revision
c6513400d84:39c49bc104d:1f3a07da9b6bcfa4733750826746bd18ac6f20db]
(alpha-unknown-openbsd6.8)
built as a cross from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99115
Uroš Bizjak changed:
What|Removed |Added
Known to work||11.0
--- Comment #3 from Uroš Bizjak ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99083
--- Comment #10 from Uroš Bizjak ---
(In reply to Richard Biener from comment #7)
> There are a lot of targets that define REG_ALLOC_ORDER ^
> HONOR_REG_ALLOC_ORDER and thus are affected by this change...
The following patch should solve this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99083
--- Comment #8 from Uroš Bizjak ---
(In reply to Richard Biener from comment #7)
> Btw, for GCC 11 it might be tempting to simply revert the "no-op" change?
I agree, this is the safest way at this time. The situation now looks like
going into
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99083
--- Comment #6 from Uroš Bizjak ---
As a side note, it is strange that ADJUST_REG_ALLOC_ORDER somehow require
REG_ALLOC_ORDER to be defined (c.f. Comment #3), while its documentation says:
The macro body should not assume anything about
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99083
--- Comment #5 from Uroš Bizjak ---
Martin, can you please benchmark the patch from Comment #4?
The patch is not totally trivial, because it introduces HONOR_REG_ALLOC_ORDER
to x86 and this define disables some other code in ira-color.c,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99083
--- Comment #4 from Uroš Bizjak ---
Created attachment 50185
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50185=edit
Proposed patch
Proposed patch that fixes ira-color.c and introduces HONOR_REG_ALLOC_ORDER.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99083
--- Comment #3 from Uroš Bizjak ---
It looks to me another one is in reload1.c, find_reg:
if (this_cost < best_cost
/* Among registers with equal cost, prefer caller-saved ones, or
use REG_ALLOC_ORDER if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99083
--- Comment #1 from Uroš Bizjak ---
This should be a no-op. According to the documentation:
--q--
Macro: REG_ALLOC_ORDER
If defined, an initializer for a vector of integers, containing the numbers
of hard registers in the order in which
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99025
--- Comment #2 from Uroš Bizjak ---
Comment on attachment 50154
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50154
gcc11-pr99025.patch
>2021-02-09 Jakub Jelinek
>+ if (SUBREG_P (operands[1]))
>+operands[1] = force_reg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98962
--- Comment #4 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #3)
> Another possibility is add x/v constraints to *andsi_1 and *anddi_1 with the
> immediates and disparage that alternative enough to reflect the fact that
> the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98961
--- Comment #3 from Uroš Bizjak ---
Please note that LZCNT insn has it own set of problems (e.g.
TARGET_AVOID_FALSE_DEP_FOR_BMI), so I'm not convinced that even:
int z (int i)
{
return i == 0;
}
benefits from using LZCNT:
0: 31 c0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98961
Uroš Bizjak changed:
What|Removed |Added
CC||ubizjak at gmail dot com
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98737
--- Comment #2 from Uroš Bizjak ---
This can be optimized with peephole2, we already have similar case in sync.md:
;; This peephole2 and following insn optimize
;; __sync_fetch_and_add (x, -N) == N into just lock {add,sub,inc,dec}
;; followed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98612
--- Comment #8 from Uroš Bizjak ---
(In reply to Hongtao.liu from comment #7)
> I asked my colleagues within intel to revise the descriptions in the
> intrinsics guide to make it more explicit about NAN operands.
>
> I'll fix this issue after
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98724
--- Comment #1 from Uroš Bizjak ---
Sorry, I don't have access to alpha anymore.
(And I'm surprised that gnat even builds, because I've never tried.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98713
--- Comment #4 from Uroš Bizjak ---
Please see PR 56309 (and PR 85559 meta bug).
Quote from Honza:
The decision on whether to use cmov or jmp was always tricky on x86
architectures. Cmov increase dependency chains, register pressure (both
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96674
--- Comment #8 from Uroš Bizjak ---
Comment on attachment 49969
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49969
Optimize combination of comparisons to dec+compare
>+/* y == XXX_MIN || x < y --> x <= y - 1 */
Can we use TYPE_MIN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98671
--- Comment #6 from Uroš Bizjak ---
(In reply to David Binderman from comment #5)
> (In reply to Uroš Bizjak from comment #4)
> > I'm not sure if solving this would bring us anything.
>
> For clarity, at very most a 4% reduction in the size of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98683
--- Comment #1 from Uroš Bizjak ---
Maybe TARGET_CANONICALIZE_COMPARISON would help here? x86 had a similar issue
with ficom x87 insn where float RTX was always the first operand, but the
compare was with the float extend of the second one.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98671
Uroš Bizjak changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98671
Uroš Bizjak changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98482
--- Comment #14 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #10)
> If we are emitting for nested functions
> pushq %r10
> 1:call__fentry__
> popq%r10
> (is it ok to misalign the stack for __fentry__?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98482
--- Comment #9 from Uroš Bizjak ---
(In reply to Topi Miettinen from comment #8)
> I'm unfortunately ignorant to GCC internals and usage of %r10, but otherwise
> the patch looks good to me.
>
> For -mcmodel=large -fPIC, the call sequence
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98482
--- Comment #5 from Uroš Bizjak ---
(In reply to Topi Miettinen from comment #4)
> Sorry, I didn't check the ABI. It seems that %r11 and maybe %r10 should be
> usable:
%r11 is already used as PROFILE_COUNT_REGISTER for !NO_PROFILE_COUNTERS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98482
--- Comment #3 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #2)
> (In reply to Hongtao.liu from comment #1)
> > and by the time of output __fentry__ in gcc, register is already accocated,
> > is there any regs supposed to be safe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98482
--- Comment #2 from Uroš Bizjak ---
(In reply to Hongtao.liu from comment #1)
> and by the time of output __fentry__ in gcc, register is already accocated,
> is there any regs supposed to be safe in the entry of function? or we need
> to spill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98567
--- Comment #2 from Uroš Bizjak ---
Comment on attachment 49901
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49901
gcc11-pr98567.patch
>+(define_insn "*bmi_blsi__cmp"
>+ [(set (reg:CCZ FLAGS_REG)
>+ (compare:CCZ
>+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98522
Uroš Bizjak changed:
What|Removed |Added
Target Milestone|--- |10.3
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98521
Uroš Bizjak changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98521
Uroš Bizjak changed:
What|Removed |Added
Ever confirmed|0 |1
Assignee|unassigned at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98522
Uroš Bizjak changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64243
Uroš Bizjak changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64243
--- Comment #5 from Uroš Bizjak ---
This is fixed in gcc-11:
--cut here--
struct TestFloat { float x; };
struct TestDouble { double x; };
struct TestFloat foo (struct TestFloat x) { return x; }
struct TestDouble bar (struct TestDouble x) {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64243
Uroš Bizjak changed:
What|Removed |Added
CC||10walls at gmail dot com
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98439
--- Comment #3 from Uroš Bizjak ---
I don't think this is a backend bug. The position of split pass in the pass
sequence assumes that no split candidates will be emitted after regstack, as
can be seen from the gate function of the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97684
Uroš Bizjak changed:
What|Removed |Added
Component|target |rtl-optimization
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98439
Uroš Bizjak changed:
What|Removed |Added
Component|target |rtl-optimization
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92658
--- Comment #22 from Uroš Bizjak ---
(In reply to Hongtao.liu from comment #21)
> Add define_code_attr like aarch64/iterators.md?
>
> --
> ;; Map rtl objects to optab names
> (define_code_attr optab [(ashift "ashl")
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96793
Uroš Bizjak changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96793
--- Comment #22 from Uroš Bizjak ---
https://gcc.gnu.org/g:edb28850520d1137d12a1cc1c0e89c11e6b0c6ef
commit r8-10691-gedb28850520d1137d12a1cc1c0e89c11e6b0c6ef
Author: Uros Bizjak
Date: Wed Dec 23 09:18:12 2020 +0100
i386: Fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96793
--- Comment #21 from Uroš Bizjak ---
https://gcc.gnu.org/g:c40b640ebcef1aae78eaca56e04d204dda9e4cad
commit r9-9126-gc40b640ebcef1aae78eaca56e04d204dda9e4cad
Author: Uros Bizjak
Date: Wed Dec 23 09:09:29 2020 +0100
i386: Fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96793
--- Comment #20 from Uroš Bizjak ---
https://gcc.gnu.org/g:0bf0e0b86d3e2f12555479096baaf0ca7a9f7ac6
commit r10-9164-g0bf0e0b86d3e2f12555479096baaf0ca7a9f7ac6
Author: Uros Bizjak
Date: Tue Dec 22 21:11:51 2020 +0100
i386: Fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96793
--- Comment #19 from Uroš Bizjak ---
https://gcc.gnu.org/g:337ed0eb490b14899f4049bc4c8922eb1d8a2e67
commit r11-6303-g337ed0eb490b14899f4049bc4c8922eb1d8a2e67
Author: Uros Bizjak
Date: Tue Dec 22 18:13:24 2020 +0100
i386: Fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98420
Bug ID: 98420
Summary: Invalid simplification of x - x with -frounding-math
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96793
Uroš Bizjak changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98060
Uroš Bizjak changed:
What|Removed |Added
Target Milestone|--- |12.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98375
Uroš Bizjak changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98375
Bug ID: 98375
Summary: [meta bug] GCC 12 pending patches
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98218
Uroš Bizjak changed:
What|Removed |Added
Severity|normal |enhancement
Target|x86_64-*-*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98218
--- Comment #3 from Uroš Bizjak ---
Testcase 1:
--cut here--
typedef short vec __attribute__((vector_size(8)));
typedef unsigned short uvec __attribute__((vector_size(8)));
vec lt (vec a, vec b) { return a < b; }
vec le (vec a, vec b) { return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98218
--- Comment #2 from Uroš Bizjak ---
Created attachment 49796
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49796=edit
Proposed patch to implement integer vector compares
Attached patch implements integer vector compares.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98169
--- Comment #7 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #6)
> Not familiar with the 64-bit vector support myself, CCing Uros on that.
PR98218
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91384
--- Comment #8 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #1)
> Started with r223689. Though, generally that change looks like a useful
> GIMPLE canonicalization.
How about we amend the above change to:
diff --git
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91384
--- Comment #7 from Uroš Bizjak ---
Still happens on trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78952
Uroš Bizjak changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78952
Uroš Bizjak changed:
What|Removed |Added
Target Milestone|--- |9.0
--- Comment #7 from Uroš Bizjak ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95046
Uroš Bizjak changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95750
Uroš Bizjak changed:
What|Removed |Added
Target Milestone|--- |11.0
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98212
--- Comment #2 from Uroš Bizjak ---
f1 is currently unoptimal by design, the compiler is unable to merge trapping
and non-trapping instructions. There is already a PR for that.
f2 is not optimal. The conditional jump to the unconditional jump
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92469
--- Comment #11 from Uroš Bizjak ---
*** Bug 98194 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98194
Uroš Bizjak changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98178
--- Comment #2 from Uroš Bizjak ---
On a related note, the combine splitter is a very mysterious beast, and does
not easily tell, why the particular combination is rejected. Without any debug
in debug logs it is very frustrating to figure out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98178
--- Comment #1 from Uroš Bizjak ---
The attached patch with the following testcase:
--cut here--
int test (int a, int b)
{
return a << (b & 31);
}
--cut here--
fails to generate a single shift insn, because it does not trigger the call to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98178
Bug ID: 98178
Summary: Combine splitter does not split to single instruction
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98086
Uroš Bizjak changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98086
--- Comment #7 from Uroš Bizjak ---
https://gcc.gnu.org/g:521c839fad4e4a30cdadda254fb3f07706285033
commit r9-9096-g521c839fad4e4a30cdadda254fb3f07706285033
Author: Uros Bizjak
Date: Thu Dec 3 19:08:23 2020 +0100
i386: Fix up
701 - 800 of 847 matches
Mail list logo
