https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115256
--- Comment #3 from Levy Hsu ---
FYI we tried serval combinations, -funroll-loops didn't cause the issue, The
link-time optimization -flto may caused the issue, we can pass with the option
[-march=native -Ofast -funroll-loops].
But compiling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115256
Bug ID: 115256
Summary: [15 Regression] 502.gcc_r Run failed with
'-march=native -Ofast -funroll-loops -flto' since
r15-571-g1e0ae1f52741f7
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115146
--- Comment #11 from Levy Hsu ---
(In reply to Uroš Bizjak from comment #8)
> (In reply to Levy Hsu from comment #5)
> > case E_V16QImode:
> > mode = V8HImode;
> > gen_shr = gen_vlshrv8hi3;
> > gen_shl = gen_vashlv8hi3;
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115146
--- Comment #7 from Levy Hsu ---
Created attachment 58236
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58236=edit
[PR]115146
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115146
--- Comment #5 from Levy Hsu ---
switch (d->vmode)
{
case E_V8QImode:
if (!TARGET_MMX_WITH_SSE)
return false;
mode = V4HImode;
gen_shr = gen_ashrv4hi3(should be gen_lshrv4hi3);
gen_shl = gen_ashlv4hi3;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107563
--- Comment #12 from Levy Hsu ---
switch (d->vmode)
{
case E_V8QImode:
if (!TARGET_MMX_WITH_SSE)
return false;
mode = V4HImode;
gen_shr = gen_ashrv4hi3(should be gen_lshrv4hi3);
gen_shl = gen_ashlv4hi3;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111858
Levy Hsu changed:
What|Removed |Added
Resolution|--- |FIXED
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111858
--- Comment #2 from Levy Hsu ---
Checked the parent commit and confirmed r14-4682-g323209cd73bf1d fixed the ICE.
Thanks~
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111858
Bug ID: 111858
Summary: [14 Regression] ICE: in vectorizable_simd_clone_call,
at tree-vect-stmts.cc:4263
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106315
--- Comment #4 from Levy Hsu ---
So I cross-compared all sizes of those .o files in make.out:
list of all diff > 2% files:
Size1: 19464 Size2: 20760 File: PUGH/SetupPGV.o
Size1: 324675 Size2: 402929 File: LocalReduce/CountFunctions.o
Size1:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106315
--- Comment #2 from Levy Hsu ---
Cheked non-LTO build (-march=native -Ofast -funroll-loops), codesize increasd
by 7.1%
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106315
Bug ID: 106315
Summary: 7.8% increased codesize on specfp 507.cactuBSSN_r
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106222
Bug ID: 106222
Summary: x86 Better code squence for __builtin_shuffle
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105643
--- Comment #6 from Levy Hsu ---
Created attachment 52997
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52997=edit
Vec different seems to related SetPixelPacket
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105643
--- Comment #5 from Levy Hsu ---
Created attachment 52996
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52996=edit
-fopt-info-vec after this commit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105643
--- Comment #4 from Levy Hsu ---
Created attachment 52995
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52995=edit
-fopt-info-vec before that commit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105643
--- Comment #3 from Levy Hsu ---
I forgot to mention, that the build time also increased by 128% on the Intel
platform above, but no performance improvement was spotted.
I'll check the objdump and see what happens.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105643
Bug ID: 105643
Summary: [13 Regression] Code-Size regression for specrate
538.imagick_r
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103997
--- Comment #14 from Levy Hsu ---
Hi Avieira and Richard
I checked the data for the last half month and you are right, that no real
regression was caused. Thank you all for the detailed explanation.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103997
--- Comment #11 from Levy Hsu ---
Hi Avieira
The baseline was one commit before. (ffc7f200adbdf47f14b3594d9b21855c19cf797a)
I'm experiencing some issue on local Vtune so I can't say which function or
front/backend was affected.
objdump shows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103997
Levy Hsu changed:
What|Removed |Added
CC||admin at levyhsu dot com
--- Comment #9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
Bug 53947 depends on bug 104058, which changed state.
Bug 104058 Summary: [12 Regression] 6-7% x264_r regression with -march=native
-Ofast -funroll-loops -flto on x86 since
r12-6420-gd3ff7420e941931d32ce2e332e7968fe67ba20af
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 104058, which changed state.
Bug 104058 Summary: [12 Regression] 6-7% x264_r regression with -march=native
-Ofast -funroll-loops -flto on x86 since
r12-6420-gd3ff7420e941931d32ce2e332e7968fe67ba20af
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104058
Levy Hsu changed:
What|Removed |Added
Resolution|--- |FIXED
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104058
Bug ID: 104058
Summary: [12 Regression] 6-7% x264_r regression with
-march=native -Ofast -funroll-loops -flto on x86 since
r12-6420-gd3ff7420e941931d32ce2e332e7968fe67ba20af
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103223
Levy changed:
What|Removed |Added
CC||admin at levyhsu dot com
--- Comment #10 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #57 from Levy ---
Thank you JiaWei for the CoreMark-Pro result.
Personally, I agree with Jim, since changing the split behaviour of try_combine
in the combine.c could affect other platforms, theoretically, we can fix it
with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
Levy changed:
What|Removed |Added
Attachment #49543|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #48 from Levy ---
Created attachment 49757
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49757=edit
Initial V1 patch on combine.c
Three patches together:
= Summary of gcc testsuite =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #47 from Levy ---
where insns are merged:
In combine.c (pass_combine)
rest_of_handle_combine()
calls:
combine_instructions()
calls:
creat_log_links() creates links of insn (768&32/36/40/44)
for both patched and unpatched version
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #46 from Levy ---
Looking at gcc/passed.def and gcc/config/riscv-passes.def:
pass_shorten_memrefs is inserted after NEXT_PASS (pass_rtl_store_motion);
NEXT_PASS (pass_rtl_store_motion);
(pass_shorten_memrefs)
NEXT_PASS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #45 from Levy ---
Basically crossed out the rtlanal.c and fwprop.c
I'm looking back at riscv.c. Since address_cost() was called by hook function
new_address_profitable_p(), may be some place uses this function would provide
more info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #44 from Levy ---
should_replace_address() in fwprop.c looks really interesting:
/* OLD is a memory address. Return whether it is good to use NEW instead,
for a memory access in the given MODE. */
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #43 from Levy ---
Thanks for pointing the hook out Jim.
for both patched and unpatched, so far I've been traced through
try_replace_in_use()
to
reload_combine_recognize_const_pattern()
to
reload_combine()
to
reload_cse_regs()
to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #41 from Levy ---
When putting the same debug_rtx(addr) at the first line of riscv_address_cost()
Unpatched one outputs:
(plus:DI (reg/f:DI 15 a5 [88])
(const_int 32 [0x20]))
(plus:DI (reg:DI 10 a0 [92])
(const_int 800
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #39 from Levy ---
Checked all pass from 250r.shorten_memrefs to 270r.ce2
In 269r.combine I saw the following combination merged the replaced address:
---
modifying insn i327:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #38 from Levy ---
Created attachment 49575
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49575=edit
riscv-shorten-memrefs_V1.patch
Did little bit change in get_si_mem_base_reg() and transform()
Now for the same c input
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #36 from Levy ---
It seems get_si_mem_base_reg() were called repeatly FOR_BB_INSNS from both
pass_shorten_memrefs::analyze and pass_shorten_memrefs::transform
Correct me if I'm wrong:
It seems we need some data structure (a linked
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #34 from Levy ---
(In reply to Jim Wilson from comment #33)
> I did say that I'm willing to fix code style issues. All major software
> projects I have worked with have coding style conventions. It makes it
> easier to maintain a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
Levy changed:
What|Removed |Added
Attachment #49542|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
Levy changed:
What|Removed |Added
Attachment #49536|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
Levy changed:
What|Removed |Added
Attachment #49534|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
Levy changed:
What|Removed |Added
Attachment #49533|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #27 from Levy ---
(In reply to Kito Cheng from comment #25)
> Seem like you have add code to gcc/optabs.h and gcc/optabs.c, however those
> functions are RISC-V specific, so I would suggest you put in riscv.c and
> riscv-protos.h.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
Levy changed:
What|Removed |Added
Attachment #49532|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
Levy changed:
What|Removed |Added
Attachment #49524|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
Levy changed:
What|Removed |Added
Attachment #49470|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #22 from Levy ---
Under condition
if (GET_MODE_CLASS (mode) == MODE_INT
&& GET_MODE_SIZE (mode) < UNITS_PER_WORD
&& can_create_pseudo_p()
&& MEM_P (src))
with var:
rtx temp_reg;
int extend =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #19 from Levy ---
Also tested code without int extend, just zero-extend with unsignedp set to 1,
Still seg fault.
if (GET_MODE_CLASS (mode) == MODE_INT
&& GET_MODE_SIZE (mode) < UNITS_PER_WORD
&&
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #18 from Levy ---
if (GET_MODE_CLASS (mode) == MODE_INT
&& GET_MODE_SIZE (mode) < UNITS_PER_WORD
&& can_create_pseudo_p()
&& MEM_P (src))
{
int extend = (LOAD_EXTEND_OP (mode) == ZERO_EXTEND);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #12 from Levy ---
(In reply to Kito Cheng from comment #11)
> > Two failed cases: shorten-memrefs-5.c & shorten-memrefs-6.c
>
> Seems like shorten_memrefs pass didn't handle zero_extend and sign_extend
> with memory.
>
> You can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #10 from Levy ---
Created attachment 49500
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49500=edit
Optimzation Patch for QI/HImode(32bit) and QI/HI/SImode(64bit)
Proposing second patch for QI/HImode(32bit) and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #9 from Levy ---
Thanks Jim. See u on Monday.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #8 from Levy ---
Created attachment 49470
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49470=edit
optimization fix for BUG 97417
proposing a temp patch here in case someone needs it, then I'll submit a full
patch with test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
Levy changed:
What|Removed |Added
CC||admin at levyhsu dot com
--- Comment #6 from
55 matches
Mail list logo
