https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113576
--- Comment #37 from Hongtao Liu ---
(In reply to Richard Biener from comment #36)
> For example with AVX512VL and the following, using -O -fgimple -mavx512vl
> we get simply
>
> notl%esi
> orl %esi, %edi
> cmpb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113576
--- Comment #38 from Hongtao Liu ---
> I think we should also mask off the upper bits of variable mask?
>
> notl%esi
> orl %esi, %edi
> notl%edi
> andl$15, %edi
> je .L3
with -mbmi,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113576
--- Comment #39 from Hongtao Liu ---
> > the question is whether that matches the semantics of GIMPLE (the padding
> > is inverted, too), whether it invokes undefined behavior (don't do it - it
> > seems for people using intrinsics that's what i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113576
--- Comment #43 from Hongtao Liu ---
> Well, yes, the discussion in this bug was whether to do this at consumers
> (that's sth new) or with all mask operations (that's how we handle
> bit-precision integer operations, so it might be relatively
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113576
--- Comment #44 from Hongtao Liu ---
>
> Note the AND is removed by combine if I add it:
>
> Successfully matched this instruction:
> (set (reg:CCZ 17 flags)
> (compare:CCZ (and:HI (not:HI (subreg:HI (reg:QI 102 [ tem_3 ]) 0))
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113576
--- Comment #45 from Hongtao Liu ---
> > There's do_store_flag to fixup for uses not in branches and
> > do_compare_and_jump for conditional jumps.
>
> reasonable enough for me.
I mean we only handle it at consumers where upper bits matters.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113576
--- Comment #57 from Hongtao Liu ---
> For dg-do run testcases I really think we should avoid those -march=
> options, because it means a lot of other stuff, BMI, LZCNT, ...
Make sense.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109885
--- Comment #4 from Hongtao Liu ---
int sum() {
int ret = 0;
for (int i=0; i<8; ++i) ret +=(0==v[i]);
return ret;
}
int sum2() {
int ret = 0;
auto m = v==0;
for (int i=0; i<8; ++i) ret += m[i];
return ret;
}
For sum, gcc t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114107
Hongtao Liu changed:
What|Removed |Added
CC||liuhongt at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114107
--- Comment #8 from Hongtao Liu ---
(In reply to Hongtao Liu from comment #7)
> perm_cost is very low in x86 backend, and it maybe ok for 128-bit vectors,
> pshufb/shufps are avaible for most cases.
> But for 256/512-bit vectors, when the permua
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114107
--- Comment #11 from Hongtao Liu ---
(In reply to N Schaeffer from comment #9)
> In addition, optimizing for size with -Os leads to a non-vectorized
> double-loop (51 bytes) while the vectorized loop with vbroadcastsd (produced
> by clang -Os) l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112325
--- Comment #9 from Hongtao Liu ---
The original case is a little different from the one in PR.
It comes from ggml
#include
#include
typedef uint16_t ggml_fp16_t;
static float table_f32_f16[1 << 16];
inline static float ggml_lookup_fp16_to_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112325
--- Comment #10 from Hongtao Liu ---
(In reply to Hongtao Liu from comment #9)
> The original case is a little different from the one in PR.
But the issue is similar, after cunrolli, GCC failed to vectorize the outer
loop.
The interesting thing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112325
--- Comment #11 from Hongtao Liu ---
>Loop body is likely going to simplify further, this is difficult
>to guess, we just decrease the result by 1/3. */
>
This is introduced by r0-68074-g91a01f21abfe19
/* Estimate number of insns of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114125
Bug ID: 114125
Summary: Support vcond_mask_qiqi and friends.
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114125
Hongtao Liu changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112325
--- Comment #14 from Hongtao Liu ---
(In reply to rguent...@suse.de from comment #13)
> On Tue, 27 Feb 2024, liuhongt at gcc dot gnu.org wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112325
> >
> > --- Comment #11 from Hongtao Liu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112325
--- Comment #16 from Hongtao Liu ---
> I'm all for removing the 1/3 for innermost loop handling (in cunroll
> the unrolled loop is then innermost). I'm more concerned about
> unrolling more than one level which is exactly what's required for
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114164
Hongtao Liu changed:
What|Removed |Added
CC||liuhongt at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114171
Hongtao Liu changed:
What|Removed |Added
CC||liuhongt at gcc dot gnu.org
Last reconf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111822
--- Comment #16 from Hongtao Liu ---
(In reply to Uroš Bizjak from comment #11)
> (In reply to Richard Biener from comment #10)
> > The easiest fix would be to refuse applying STV to a insn that
> > can_throw_internal () (that's an insn that has
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110027
--- Comment #12 from Hongtao Liu ---
(In reply to Sam James from comment #11)
> Calling it a 11..14 regression as we know 14 is bad and 7.5 is OK, but I
> can't test 11/12 on an avx512 machine right now.
I can't reproduce that with 11/12, but w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110027
--- Comment #13 from Hongtao Liu ---
So the stack is like
--- stack top
-32
- (offset -32)
-64 (32 bytes redzone)
- (offset -64)
-128 (64 bytes __m512)
(offset -128)
(32-bytes redzone)
---(offset -1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111731
Hongtao Liu changed:
What|Removed |Added
CC||liuhongt at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110027
--- Comment #14 from Hongtao Liu ---
diff --git a/gcc/cfgexpand.cc b/gcc/cfgexpand.cc
index 0de299c62e3..92062378d8e 100644
--- a/gcc/cfgexpand.cc
+++ b/gcc/cfgexpand.cc
@@ -1214,7 +1214,7 @@ expand_stack_vars (bool (*pred) (size_t), class
stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111822
Hongtao Liu changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110027
--- Comment #15 from Hongtao Liu ---
A patch is posted at
https://gcc.gnu.org/pipermail/gcc-patches/2024-March/647604.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114334
Hongtao Liu changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66862
--- Comment #5 from Hongtao Liu ---
> Now, it seems AVX512BW (and AVX512VL in some cases) has the needed
> instructions,
> in particular VMOVDQU{8,16}, but it is not reflected in maskload and
> maskstore expanders. CCing Kyrill and Uros on this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114334
Hongtao Liu changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114347
--- Comment #9 from Hongtao Liu ---
(In reply to Richard Biener from comment #7)
> (In reply to Jakub Jelinek from comment #6)
> > You can use -fexcess-precision=16 if you don't want treating _Float16 and
> > __bf16 as having excess precision.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67683
Hongtao Liu changed:
What|Removed |Added
CC||liuhongt at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114396
--- Comment #15 from Hongtao Liu ---
(In reply to Richard Biener from comment #9)
> (In reply to Robin Dapp from comment #8)
> > No fallout on x86 or aarch64.
> >
> > Of course using false instead of TYPE_SIGN (utype) is also possible and
> > m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114396
Hongtao Liu changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #16 from Hongtao Liu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114396
--- Comment #17 from Hongtao Liu ---
> >
> > The to_mpz args look like they could be mixing signs as well:
> >
I tries below, looks like mixing signs works well.
debug show step_expr is -5 and signed.
short a = 0xF;
short b[16];
unsigned shor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92080
Hongtao Liu changed:
What|Removed |Added
CC||liuhongt at gcc dot gnu.org
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92080
--- Comment #9 from Hongtao Liu ---
> If we were to expose that vpxor before postreload we'd likely CSE but
> we have
>
> 5: xmm0:V4SI=const_vector
> REG_EQUIV const_vector
> 6: [`b']=xmm0:V4SI
> 7: xmm0:V8HI=const_vector
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114396
--- Comment #20 from Hongtao Liu ---
(In reply to JuzheZhong from comment #19)
> I think it's better to add pr114396.c into vect testsuite instead of x86
> target test since it's the bug not only happens on x86.
Sure, there's no target specific
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114396
Hongtao Liu changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114427
Bug ID: 114427
Summary: [x86] ec_pack_truncv8si/v4si can be optimized with
pblendw instead of pand for AVX2 target
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114428
Bug ID: 114428
Summary: [x86] psrad xmm, xmm, 16 and pand xmm, const_vector
(0x x4) can be optimized to psrld
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114429
Bug ID: 114429
Summary: [x86] (neg a) ashifrt>> 31 can be optimized to a > 0.
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114429
Hongtao Liu changed:
What|Removed |Added
Target||x86_64-*-* i?86-*-*
--- Comment #1 from H
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114429
--- Comment #2 from Hongtao Liu ---
(In reply to Hongtao Liu from comment #1)
> when x is INT_MIN, I assume -x is UD, so compiler can do anything.
> otherwise, (-x) >> 31 is just x > 0.
> From rtl view. neg of INT_MIN is assumed to 0 after it's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114429
Hongtao Liu changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114471
Hongtao Liu changed:
What|Removed |Added
CC||liuhongt at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114471
--- Comment #6 from Hongtao Liu ---
(In reply to Hongtao Liu from comment #5)
> Maybe we should always use kmask under AVX512, currently only >= 128-bits
> vector of vector _Float16 use kmask, < 128 bits vector still use vector mask.
>
and we n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114514
Bug ID: 114514
Summary: v16qi >> 7 can be optimized with vpcmpgtb
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114514
--- Comment #3 from Hongtao Liu ---
(In reply to Andrew Pinski from comment #1)
> Confirmed.
>
> Note non sign bit can be improved too:
> ```
I assume you're talking about broadcast from imm or directly from constant
pool. GCC chooses the forme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114544
Bug ID: 114544
Summary: [x86] stv should transform (subreg DI (V1TI) 8) as
(vec_select:DI (V2DI) (const_int 1))
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114544
--- Comment #1 from Hongtao Liu ---
20590;; Turn SImode or DImode extraction from arbitrary SSE/AVX/AVX512F
20591;; vector modes into vec_extract*.
20592(define_split
20593 [(set (match_operand:SWI48x 0 "nonimmediate_operand")
20594(sub
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114544
--- Comment #2 from Hongtao Liu ---
Also for
void
foo2 (v128_t* a, v128_t* b)
{
c = (*a & *b)+ *b;
}
(insn 9 8 10 2 (set (reg:V1TI 108 [ _3 ])
(and:V1TI (reg:V1TI 99 [ _2 ])
(mem:V1TI (reg:DI 113) [1 *a_6(D)+0 S16 A128])
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114556
Bug ID: 114556
Summary: weird loop unrolling when there's attribute aligned in
side the loop
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114570
Bug ID: 114570
Summary: GCC doesn't perform good loop invariant code motion
for very long vector operations.
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Sev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113744
Hongtao Liu changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116157
Hongtao Liu changed:
What|Removed |Added
CC||liuhongt at gcc dot gnu.org
S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85236
Hongtao Liu changed:
What|Removed |Added
CC||binklings at 163 dot com
--- Comment #8 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116122
Hongtao Liu changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115981
--- Comment #4 from Hongtao Liu ---
(In reply to Jakub Jelinek from comment #3)
> Created attachment 58786 [details]
> gcc15-pr115981.patch
>
> Untested fix. As since that commit it checks swap_commutative_operands_p:
> 1) CONST_VECTOR I think
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113744
Hongtao Liu changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89749
Hongtao Liu changed:
What|Removed |Added
Resolution|--- |FIXED
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116096
Hongtao Liu changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115021
Hongtao Liu changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116274
Hongtao Liu changed:
What|Removed |Added
CC||liuhongt at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116274
--- Comment #5 from Hongtao Liu ---
For non-avx case, looks like it hits here
748 /* Special case TImode to 128-bit vector conversions via V2DI. */
749 if (VECTOR_MODE_P (mode)
75
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116274
--- Comment #6 from Hongtao Liu ---
(In reply to Hongtao Liu from comment #5)
> For non-avx case, looks like it hits here
>
> 748 /* Special case TImode to 128-bit vector conversions via V2DI. */
>
Prevent that in reload, we get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113729
Hongtao Liu changed:
What|Removed |Added
Keywords||missed-optimization
Resolution|--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116174
Hongtao Liu changed:
What|Removed |Added
CC||liuhongt at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115756
Hongtao Liu changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115749
Bug 115749 depends on bug 115756, which changed state.
Bug 115756 Summary: default tuning for x86_64 produces shifts for `*240`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115756
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115749
Hongtao Liu changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113600
--- Comment #10 from Hongtao Liu ---
I think it should be fixed by r15-2820-gab18785840d7b8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81602
Hongtao Liu changed:
What|Removed |Added
CC||liuhongt at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116274
--- Comment #8 from Hongtao Liu ---
>
> codegen is probably an RA/LRA artifact caused by bad instruction constraints
> and the refuse to reload to a gpr. Not sure if a move high to gpr is a
> thing,
> pextrq would work for sure. But an unpck
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116174
Hongtao Liu changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115982
Hongtao Liu changed:
What|Removed |Added
Resolution|--- |FIXED
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115683
--- Comment #6 from Hongtao Liu ---
(In reply to Uroš Bizjak from comment #5)
> (In reply to Hongtao Liu from comment #0)
>
> > g++: g++.target/i386/pr100637-1b.C
> > g++: g++.target/i386/pr100637-1w.C
> > g++: g++.target/i386/pr103861-1.C
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116497
Hongtao Liu changed:
What|Removed |Added
CC||liuhongt at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116512
Hongtao Liu changed:
What|Removed |Added
Last reconfirmed|2024-08-28 00:00:00 |
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116512
--- Comment #4 from Hongtao Liu ---
gdb shows crtl->return_rtx is
21(parallel/i:BLK [
22(expr_list:REG_DEP_TRUE (reg:XI 20 xmm0)
23(c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116512
--- Comment #6 from Hongtao Liu ---
(In reply to Andrew Pinski from comment #5)
> (In reply to Hongtao Liu from comment #4)
> > gdb shows crtl->return_rtx is
> >
> > 21(parallel/i:BLK [
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116512
Hongtao Liu changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116582
--- Comment #5 from Hongtao Liu ---
(In reply to Richard Biener from comment #4)
> (In reply to Jan Hubicka from comment #3)
> > Just for completeness the codegen for parest sparse matrix multiply is:
> >
> > 0.31 │320: kmovb %k1,%k
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116617
Hongtao Liu changed:
What|Removed |Added
CC||haochen.jiang at intel dot com,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116617
Hongtao Liu changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116658
Bug ID: 116658
Summary: [GCC15 regression] ICE in vect_is_slp_load_node
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116674
Bug ID: 116674
Summary: [15 regression] ICE in vectorizable_simd_clone_call
bisected to r15-3509-gd34cda72098867
Product: gcc
Version: 15.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116674
--- Comment #1 from Hongtao Liu ---
Created attachment 59094
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59094&action=edit
test.i
A more reduced case.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116675
Hongtao Liu changed:
What|Removed |Added
CC||liuhongt at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114544
--- Comment #3 from Hongtao Liu ---
<__umodti3>:
...
37 58: 66 48 0f 6e c7 movq %rdi,%xmm0
38 5d: 66 48 0f 6e d6 movq %rsi,%xmm2
39 62: 66 0f 6c c2 punpcklqdq %xmm2,%xmm0
40 66:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113288
Hongtao Liu changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66862
Hongtao Liu changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114591
Hongtao Liu changed:
What|Removed |Added
CC||liuhongt at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114591
--- Comment #5 from Hongtao Liu ---
> My experience is memory cost for the operand with rm or separate r, m is
> different which impacts RA decision.
>
> https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595573.html
Change operands[1] alterna
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114591
--- Comment #9 from Hongtao Liu ---
>
> It looks that different modes of memory read confuse LRA to not CSE the read.
>
> IMO, if the preloaded value is later accessed in different modes, LRA should
> leave it. Alternatively, LRA should CSE m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114591
--- Comment #11 from Hongtao Liu ---
unsigned v;
long long v2;
char foo ()
{
v2 = v;
return v;
}
This is related to *movqi_internal, and codegen has been worse since gcc8.1
foo:
movlv(%rip), %eax
movq%rax, v2(%r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114591
--- Comment #12 from Hongtao Liu ---
short a;
short c;
short d;
void
foo (short b, short f)
{
c = b + a;
d = f + a;
}
foo(short, short):
addwa(%rip), %di
addwa(%rip), %si
movw%di, c(%rip)
movw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110027
--- Comment #19 from Hongtao Liu ---
(In reply to Jakub Jelinek from comment #17)
> Both of the posted patches are incorrect, this needs to be fixed in
> asan_emit_stack_protection, account for the different offsets[0] which
> happens when a sta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114591
--- Comment #15 from Hongtao Liu ---
> I don't see this as problematic. IIRC, there was a discussion in the past
> that a couple (two?) memory accesses from the same location close to each
> other can be faster (so, -O2, not -Os) than preloading
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114591
--- Comment #16 from Hongtao Liu ---
>
> 4952 /* See if a MEM has already been loaded with a widening operation;
> 4953 if it has, we can use a subreg of that. Many CISC machines
> 4954 also have such operations, but this
1 - 100 of 542 matches
Mail list logo
