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: r9
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&action=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 #37 from Kito Cheng ---
Maybe we could add a parameter to indicate the type of memory access,
plain_mem, zext_mem or sext_mem for pass_shorten_memrefs::get_si_mem_base_reg.
e.g.
for (int i = 0; i < 2; i++)
{
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 li
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #35 from Jim Wilson ---
By combine issue, are you referring to the regression I mentioned in comment 3
and filed as bug 97747? We can handle that as a separate issue. It should be
uncommon. I expect to get much more benefit from th
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 la
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #33 from Jim Wilson ---
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 large software base when everything is using
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
--- Comment #30 from Jim Wilson ---
Looking at your v2 patch, the first verison fails because you are passing
mismatched modes to emit_move_insn. The version with gen_lowpart solves that
problem, but fails because of infinite recursion.
The v4
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.
No
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
--- Comment #25 from Kito Cheng ---
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 #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 = (LOAD_EXT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #21 from Jim Wilson ---
I submitted my testcase as 97747 so it will get more attention.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #20 from Jim Wilson ---
Maybe convert_to_mode is recursively calling convert_to_mode until you run out
of stack space. You can use --save-temps to generate a .i preprocessed file
form your input testcasxe, then run cc1 under gdb. Yo
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
&& can_create_pseu
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);
r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #17 from Jim Wilson ---
Yes, LOAD_EXTEND_OP is a good suggestion. We can maybe do something like
int extend = (LOAD_EXTEND_OP (mode) == ZERO_EXTEND);
temp_reg = force_reg (word_mode, convert_to_mode (word_mode, src, extend));
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #16 from Kito Cheng ---
> Or maybe we make the choice of zero-extend or sign-extend depend on the mode,
> and use zero-extend for smaller than SImode and sign-extend for SImode and
> larger.
Maybe depend on LOAD_EXTEND_OP?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #15 from Jim Wilson ---
I tried testing your first patch. I just built unpatched/patch
rv32-elf/rv64-linux toolchains and used nm/objdump to look at libraries like
libc, libstdc++, libm.
I managed to find a testcase from glibc that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #14 from Jim Wilson ---
Actually, for the SImode to DImode conversion, zero extending is unlikely to be
correct in that case. The rv64 'w' instructions require the input to be
sign-extended from 32-bits to 64-bits, so a sign-extend i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #13 from Jim Wilson ---
The attachments show the entire riscv.c file being deleted and then readded
with your change. This is due to a line ending problem. The original file has
the unix style linefeed and the new file has the windo
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 tak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
Kito Cheng changed:
What|Removed |Added
CC||kito at gcc dot gnu.org
--- Comment #11 fro
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&action=edit
Optimzation Patch for QI/HImode(32bit) and QI/HI/SImode(64bit)
Proposing second patch for QI/HImode(32bit) and QI/HI/SI
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&action=edit
optimization fix for BUG 97417
proposing a temp patch here in case someone needs it, then I'll submit a full
patch with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #7 from Jim Wilson ---
That patch is basically correct. I would suggest using gen_lowpart instead of
gen_rtx_SUBREG as a minor cleanup. It will do the same thing, and is shorter
and easier to read.
There is one problem here that yo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
Levy changed:
What|Removed |Added
CC||admin at levyhsu dot com
--- Comment #6 from Levy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #5 from Jim Wilson ---
Yes, the volatile is the problem. We need to disable some optimizations like
the combiner to avoid breaking the semantics of volatile. However, if you try
looking at other ports, like arm, you can see that the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #4 from jiawei ---
I had did some tests with this problem and find:
foo.c
#include
extern volatile bool active;
int foo(void)
{
if (!active) {
return 42;
} else {
return -42;
}
}
code generated in foo.s
foo:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #3 from Jim Wilson ---
The basic idea here is that the movqi pattern in riscv.md currently emits RTL
for a load that looks like this
(set (reg:QI target) (mem:QI (address)))
As an experiment, we want to try changing that to somethin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
jiawei changed:
What|Removed |Added
CC||jiawei at iscas dot ac.cn
--- Comment #2 from j
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
Jim Wilson changed:
What|Removed |Added
CC||wilson at gcc dot gnu.org
Statu
39 matches
Mail list logo
