Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zhongyunde at tom dot com
Target Milestone: ---
For the following code, we can known init the array C16DD is always
consecutive, so we can use the more bigger mode size.
test base on the
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zhongyunde at tom dot com
Target Milestone: ---
For the following code, we can known the variable C05A1 is only used for
the offset of array Dest and Src, and the unit size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95019
--- Comment #2 from zhongyunde at tom dot com ---
It is a generic issue for all targets, such as x86, it also don't enpand IVOPTs
as index is not used for DEST and Src directly. we may need expand IVOPTs, then
different targets can s
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zhongyunde at tom dot com
Target Milestone: ---
rtx_insn *
prepare_copy_insn (rtx reg, rtx exp)
{
...
else
{
rtx_insn *insn = emit_insn (gen_rtx_SET (reg, exp));
if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95210
--- Comment #1 from zhongyunde at tom dot com ---
patch for this issue.
@ linux-9z2e in ~/software/gcc/gcc on git:master o [23:02:26]
$ git diff
diff --git a/gcc/gcse.c b/gcc/gcse.c
index 8b9518e..65982ec 100644
--- a/gcc/gcse.c
+++ b/gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95210
zhongyunde at tom dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95267
zhongyunde at tom dot com changed:
What|Removed |Added
CC||zhongyunde at tom dot com
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zhongyunde at tom dot com
Target Milestone: ---
In some target, it is limited to issue two insns with change the same
register.(The insn 73 start with insn:TI, so it will be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95696
zhongyunde at tom dot com changed:
What|Removed |Added
CC||zhongyunde at tom dot com
: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zhongyunde at tom dot com
Target Milestone: ---
For the following code, as instruction strh only store the low 16-bits value,
so the 'and w2, w2, 65535 ' is redundant.
test base on the ARM64 gcc 8.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96031
--- Comment #1 from zhongyunde at tom dot com ---
this may can be enhance by ivopts.
If the case adjusted as following, then the 'and w2, w2, 65535 ' will
disappear.
typedef unsigned int UINT32;
typedef unsigned short UINT16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95696
--- Comment #3 from zhongyunde at tom dot com ---
(In reply to Richard Biener from comment #2)
> Please send patches to gcc-patc...@gcc.gnu.org
I have send this patch by email according your suggestion, please give me some
advice, thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96031
--- Comment #3 from zhongyunde at tom dot com ---
I find there is some different between the two cases during in ivopts.
For the 2nd case, a UINT32 type iv sum is choosed
[local count: 955630224]:
# sum_15 = PHI <0(5), sum_
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zhongyunde at tom dot com
Target Milestone: ---
For the following code, we can known the local array a_1 is aligned 64 bytes,
but now gcc only aligned to default 32 bytes for related anchor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95696
--- Comment #6 from zhongyunde at tom dot com ---
Thanks for you notes and I thinks this issue can be closed now.
It doesn't need to handle of non-SMS cases as they'll reschedule in general,
which is good for performance under my test.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96427
--- Comment #2 from zhongyunde at tom dot com ---
should the data alignment honor the user specified ?
Now, it seems compiler _do_ align the initializer according align load.
so even if the local array doesn't specify the __attrib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93102
--- Comment #4 from zhongyunde at tom dot com ---
case from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96427 generates *.LC0,
but don't emit an aggregate copy a_1 = *.LC0, i.e. it is legal even for
non-const local array.
typedef int
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zhongyunde at tom dot com
Target Milestone: ---
For the following case, we can easy known the while loop will execute once, but
with newest gcc 10.2, it still generated suboptimal code with condition
expression.
void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96427
--- Comment #6 from zhongyunde at tom dot com ---
Created attachment 49087
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49087&action=edit
adjust the alignment according the attibute
If user don't specify the alignment, so we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96031
--- Comment #4 from zhongyunde at tom dot com ---
> As for ivopt, I can see a minor improvement by replacing != exit condition
> with <=, thus saving add 2 instruction computing _22, which happens to
> "disable" the wr
20 matches
Mail list logo
