https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116030
--- Comment #2 from HaoChen Gui ---
Peter, the root cause of the issue is the combine is done at ira pass. There is
no split pass after ira and reload. So the split has to been done after reload,
which causes the ICE. Jeff (Jiufu) is working on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113325
HaoChen Gui changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115648
--- Comment #1 from HaoChen Gui ---
The patch replaced rtx cost comparison with insn cost comparison. Some
replacements can be done before but can't now. Or vice versa. Please check the
fwprop dump log via -fdump-rtl-fwprop1-details and judge if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114732
--- Comment #6 from HaoChen Gui ---
(In reply to Segher Boessenkool from comment #3)
> 1001, 0101, 0011 I mean of course.
>
> In some ways CCmode models this better than CCFPmode, but we do not actually
> model
> the SO bit (bit 3) at all in CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114732
--- Comment #1 from HaoChen Gui ---
A straightforward test case. It passes when compiling with O0 and aborts when
compiling with O2.
//test.c
#include
#define BCD_POS0 12// 0xC
#define BCD_NEG 13// 0xD
void abort (void);
vecto
onent: target
Assignee: unassigned at gcc dot gnu.org
Reporter: guihaoc at gcc dot gnu.org
Target Milestone: ---
//test.c
int
foo (vector unsigned char a, vector unsigned char b)
{
return __builtin_vec_bcdsub_ge (a, b, 0) != 1;
}
//assembly
bcdsub. 2,2,3,0
|RESOLVED
CC||guihaoc at gcc dot gnu.org
--- Comment #2 from HaoChen Gui ---
It's already fixed by f4a3cea3fb02. Now it generates a single rlwimi.
rlwimi 3,3,16,0,31-16
Assignee: unassigned at gcc dot gnu.org
Reporter: guihaoc at gcc dot gnu.org
Target Milestone: ---
//test case
void* foo (void* s1)
{
return __builtin_memset (s1, 0, 32);
}
//assembly
vspltisw 0,0
li 10,16
xxpermdi 0,32,32,2
stxvd2x 0,0,3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112707
HaoChen Gui changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112707
--- Comment #9 from HaoChen Gui ---
(In reply to Segher Boessenkool from comment #8)
> Yeah, it tested for ISA 2.04 before. That was an attempt at including 476
> probably?
>
> We really should have a TARGET_FCTID, on for TARGET_POWERPC64 or f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112707
HaoChen Gui changed:
What|Removed |Added
CC||linkw at gcc dot gnu.org
--- Comment #4 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111449
HaoChen Gui changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112417
HaoChen Gui changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |guihaoc at gcc dot
gnu.org
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: guihaoc at gcc dot gnu.org
Target Milestone: ---
//test.c
void * foo (void * p)
{
if (p)
__builtin_return (p);
}
when compiling it with mno-vsx on ppc64, it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88558
HaoChen Gui changed:
What|Removed |Added
CC||guihaoc at gcc dot gnu.org
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: guihaoc at gcc dot gnu.org
Target Milestone: ---
int compare (const char* s1, const char* s2)
{
return __builtin_memcmp (s1, s2, 16) == 0;
}
trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96762
HaoChen Gui changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108812
HaoChen Gui changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110034
HaoChen Gui changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108728
HaoChen Gui changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110034
--- Comment #5 from HaoChen Gui ---
(In reply to Vladimir Makarov from comment #4)
> Thank you for providing the test case.
>
> To be honest I don't see why assigning to hr3 to r134 is better.
> Currently we have the following assignments:
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106769
HaoChen Gui changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110429
HaoChen Gui changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103605
HaoChen Gui changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104124
HaoChen Gui changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107013
HaoChen Gui changed:
What|Removed |Added
CC||joseph at codesourcery dot com
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110331
--- Comment #1 from HaoChen Gui ---
Even the P9 assembly is not good, as vextu* has a higher lantency than mfvsrd.
li 9,12
vextubrx 3,9,2
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: guihaoc at gcc dot gnu.org
Target Milestone: ---
//test.c
#include
void extract_int_2 (int *p, vector int a) { *p = vec_extract (a, 2); }
On P9 LE, it generates
xxextractuw 34,34,4
stxsiwx 34,0,3
The
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: guihaoc at gcc dot gnu.org
Target Milestone: ---
//test.c
#include
#ifdef __BIG_ENDIAN__
#define LANE_B 3
#else
#define LANE_B 12
#endif
unsigned char foo1 (vector unsigned char v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106769
--- Comment #3 from HaoChen Gui ---
(In reply to Peter Bergner from comment #2)
> I wonder if Ajit's REE changes catch this unneeded zero extension?
mfvsrwz can be defined as a zero-extend on a vector select other than a SI mode
move from "wa"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106769
HaoChen Gui changed:
What|Removed |Added
Last reconfirmed||2023-05-31
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110034
--- Comment #3 from HaoChen Gui ---
Created attachment 55215
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55215&action=edit
ira dump
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110034
HaoChen Gui changed:
What|Removed |Added
CC||guihaoc at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106769
HaoChen Gui changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |guihaoc at gcc dot
gnu.org
IRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: guihaoc at gcc dot gnu.org
Target Milestone: ---
Followings are ira dumps from a test case. r134 has only one cp(shuffle) with
r173. The r173 and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54063
HaoChen Gui changed:
What|Removed |Added
CC||guihaoc at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103628
HaoChen Gui changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |guihaoc at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100952
HaoChen Gui changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
|RESOLVED
Assignee|unassigned at gcc dot gnu.org |guihaoc at gcc dot
gnu.org
CC||guihaoc at gcc dot gnu.org
--- Comment #17 from HaoChen Gui ---
Both issues are fixed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108004
--- Comment #4 from HaoChen Gui ---
$cat asm_test.c
#include
unsigned long foo() {
unsigned long res;
__asm__ ("li 3,0x\n\t"
"li 4,0xfff1\n\t"
"and. 3,3,4\n\t"
"mfcr %0"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108004
--- Comment #3 from HaoChen Gui ---
(In reply to Andrew Pinski from comment #2)
> Especially when it comes to signed comparisons.
>From the ISA,
For all fixed-point instructions in which Rc=1, and for
addic., andi., and andis., the first three
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: guihaoc at gcc dot gnu.org
Target Milestone: ---
//test case
int foo (int a, int b, int c, int d)
{
return (a & b) > 0 ? c : d;
}
//assemble on P9
and 3,3,4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103109
--- Comment #4 from HaoChen Gui ---
(In reply to Peter Bergner from comment #3)
> (In reply to HaoChen Gui from comment #2)
> > Fixed by r13-2107.
>
> This is marked version = GCC 12. Were you planning on backporting this?
Not sure if the pa
Assignee: unassigned at gcc dot gnu.org
Reporter: guihaoc at gcc dot gnu.org
Target Milestone: ---
Could we add fmin/fmax to RTL codes so that the C standard fmin/fmax can be
represented in RTL without UNSPECs? Currently we only have smin/smax that are
not valid for NaNs, or when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102316
HaoChen Gui changed:
What|Removed |Added
CC||guihaoc at gcc dot gnu.org
||guihaoc at gcc dot gnu.org
Status|UNCONFIRMED |RESOLVED
--- Comment #2 from HaoChen Gui ---
Fixed by r13-2107.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102146
--- Comment #20 from HaoChen Gui ---
(In reply to Segher Boessenkool from comment #19)
> Hi guys,
>
> What testcases are still failing? I'm a bit lost :-)
pr56605.c is still not fixed.
+FAIL: gcc.target/powerpc/pr56605.c scan-rtl-dump-times
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103498
HaoChen Gui changed:
What|Removed |Added
CC||guihaoc at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95737
HaoChen Gui changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100694
--- Comment #6 from HaoChen Gui ---
I made a patch to convert ashift to move when the second operand is const0_rtx.
With the patch, the expand dump is just like aarch64's. But the problem is
still there.
I tested the patch with SPECint. All the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100996
--- Comment #2 from HaoChen Gui ---
(In reply to acsawdey from comment #0)
> The fusion-p10-addadd.c test case does not get vector add-add fusion when
> compiling with -m32:
>
> /home/sawdey/work/gcc/trunk/build/gcc/xgcc
> -B/home/sawdey/work/g
|RESOLVED
CC||guihaoc at gcc dot gnu.org
--- Comment #1 from HaoChen Gui ---
(In reply to acsawdey from comment #0)
> The fusion-p10-addadd.c test case does not get vector add-add fusion when
> compiling with -m32:
>
> /home
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100694
HaoChen Gui changed:
What|Removed |Added
CC||guihaoc at gcc dot gnu.org
--- Comment
at gcc dot gnu.org |guihaoc at gcc dot
gnu.org
Resolution|--- |FIXED
--- Comment #18 from HaoChen Gui ---
Fixed by r13-1131
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102146
--- Comment #15 from HaoChen Gui ---
As r12-8128 was revoked, failure of pr56605.c is still not fixed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105414
HaoChen Gui changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105414
--- Comment #8 from HaoChen Gui ---
(In reply to Jakub Jelinek from comment #7)
> Sure, but you don't want to do that at least if flag_trapping_math.
> Otherwise, the predicate would be tree_expr_signaling_nan_p and real_nan
> function with "",
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105414
--- Comment #6 from HaoChen Gui ---
(In reply to Richard Biener from comment #4)
> I think you want
>
> (if (!tree_expr_maybe_signaling_nan_p (@0))
> ...
>
> instead.
Thanks so much for comments. Do we have a way to return a NaN directly in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105414
--- Comment #3 from HaoChen Gui ---
For fmin/max behavior, I referred the this ticket.
https://sourceware.org/bugzilla/show_bug.cgi?id=20947
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105414
--- Comment #2 from HaoChen Gui ---
(In reply to Andrew Pinski from comment #1)
> What target is this on?
I tested it on ppc64le. But I think it should be on all targets?
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: guihaoc at gcc dot gnu.org
Target Milestone: ---
gcc -O0 -fsignaling-nans -D_WANT_SNAN -lm -o fmin fmin.c && ./fmin
(snan, snan), fmin: nan
gcc -O3 -fsignaling-nans -D_WANT_SNAN -lm -o fmi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103605
--- Comment #6 from HaoChen Gui ---
gcc -O0 -fsignaling-nans -D_WANT_SNAN -lm -o main main.c && ./main
(nan, 3.0), fmin: 3.0, builtin: 3.0, xsmincdp: 3.0, xsmindp: 3.0
(3.0, nan), fmin: 3.0, builtin: nan, xsmincdp: nan, xsmindp: 3.0
(snan, 3.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103605
HaoChen Gui changed:
What|Removed |Added
CC||guihaoc at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102146
--- Comment #10 from HaoChen Gui ---
(In reply to HaoChen Gui from comment #9)
> Could you backport the patch to GCC11? Thanks.
Please ignore it as the patch has problem. Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102146
--- Comment #9 from HaoChen Gui ---
Could you backport the patch to GCC11? Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105030
--- Comment #13 from HaoChen Gui ---
Could we use the original alias set if the tree code of 'atemp' is var_decl? Is
it safe? In which situation we shall use alias-set zero? Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105030
--- Comment #11 from HaoChen Gui ---
I tested C source code with Ofast. The Ofast enables data store race. It should
do store motion but it fails. The problem is on cselim pass. It does
conditional store replacement. The 'atemp' is converted to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102146
--- Comment #5 from HaoChen Gui ---
For prefix-no-update.c, the patch Segher proposed in PR103197 could fix it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102146
--- Comment #4 from HaoChen Gui ---
(In reply to Richard Biener from comment #2)
> What's the status on the remaining failures?
For pr56605.c，I already submitted a patch. Waiting for review.
https://gcc.gnu.org/pipermail/gcc-patches/2022-Februa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105030
--- Comment #9 from HaoChen Gui ---
Escaped for 'atemp' doesn't be set with Fortran source code, while it's set
with C source code. 'auto_var_in_fn_p + pt_solution_includes' works for Fortran
code. But if the function is a head of the loop in Fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105030
--- Comment #7 from HaoChen Gui ---
The original case comes from a Fortran program. I rewrote it with C. As the
arguments are passed by reference in Fortran (by default), the problem is
common. But I am not sure if it has a large performance imp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105030
--- Comment #5 from HaoChen Gui ---
(In reply to Richard Biener from comment #4)
> something like
>
> void *bar (void *x)
> {
> *(double *)x = 1.;
> }
>
> void foo(int n)
> {
>double atemp;
>pthread_create (..., bar, &atemp);
>fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105030
--- Comment #3 from HaoChen Gui ---
(In reply to Richard Biener from comment #2)
> That occured to me as well - I think the answer is maybe. In principle
> foo() could launch a thread and make the 'atemp' available to it. As long
> as foo() ou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105030
HaoChen Gui changed:
What|Removed |Added
Host||powerpc-*-linux-gnu
--- Comment #1 from H
erity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: guihaoc at gcc dot gnu.org
Target Milestone: ---
// source code
extern void bar (double *, int);
void foo (double a[], int n)
{
double atemp = 0.5;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103316
HaoChen Gui changed:
What|Removed |Added
CC||guihaoc at gcc dot gnu.org
--- Comment
|--- |INVALID
CC||guihaoc at gcc dot gnu.org
--- Comment #1 from HaoChen Gui ---
Tested gcc11 on Power8 BE. Unable to reproduce this issue. The issue should be
already fixed by r11-5613-g404d0ca7820bbf258e2edfac423403ee31b48a7b.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103124
HaoChen Gui changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100952
--- Comment #16 from HaoChen Gui ---
prefix-no-update.c should be fixed by the patch Segher proposed in PR103197.
pr56605.c got a wrong fixed and failed with GCC11. I will submit a patch to fix
it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103197
HaoChen Gui changed:
What|Removed |Added
CC||guihaoc at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95737
--- Comment #9 from HaoChen Gui ---
Add a pattern to convert the plus mode to DI.
+(define_insn_and_split "*my_split"
+ [(set (match_operand:DI 0 "gpc_reg_operand")
+ (sign_extend:DI (plus:SI (match_operand:SI 1 "ca_operand")
+
|--- |FIXED
CC||guihaoc at gcc dot gnu.org
--- Comment #4 from HaoChen Gui ---
I committed a patch (r12-4987) which is related to this issue. But it doesn't
behave as the ticket expects. With the patch, vec_min/max is bound to
xv[min|m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95737
HaoChen Gui changed:
What|Removed |Added
CC||guihaoc at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103784
--- Comment #4 from HaoChen Gui ---
output with "-fdump-tree-optimized=/dev/stdout"
;; Function foo (foo, funcdef_no=0, decl_uid=3317, cgraph_uid=1,
symbol_order=0)
Removing basic block 5
_Bool foo (int a, int b)
{
_Bool _1;
_Bool _5;
[
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103784
--- Comment #2 from HaoChen Gui ---
Sorry, I pasted wrong codes. Here are the correct ones.
//test.c
#include
bool foo (int a, int b)
{
if (a > 2)
return false;
if (b < 10)
return true;
return false;
}
//assembly with the trunk
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: guihaoc at gcc dot gnu.org
Target Milestone: ---
//test.c
#include
bool foo (int a, int b)
{
if (a > 2)
return false;
if (b < 10)
return true;
return true;
}
//assembly with trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100952
--- Comment #13 from HaoChen Gui ---
Issue for fusion-p10-ldcmpi.c was fixed by r12-1655.
https://gcc.gnu.org/pipermail/gcc-cvs/2021-June/349357.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100736
--- Comment #4 from HaoChen Gui ---
Yes, there is a question. With my patch, the test case generates following
assembly. Seems they have the same latency (cror vs. crnot). I wonder why we
need reverse the CR bit comparison when finite-math-only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100736
HaoChen Gui changed:
What|Removed |Added
CC||guihaoc at gcc dot gnu.org
--- Comment
||guihaoc at gcc dot gnu.org
Status|NEW |RESOLVED
--- Comment #3 from HaoChen Gui ---
Fixed on trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103124
--- Comment #5 from HaoChen Gui ---
(In reply to Segher Boessenkool from comment #4)
> Skipping mode TI for zero_extend lowering.
> Splitting mode TI for ashift lowering with shift amounts =
> Splitting mode TI for lshiftrt lowering with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93453
--- Comment #8 from HaoChen Gui ---
I refined the patch and put all things in a helper - change_pseudo_and_mask. As
you mentioned, it's still a band-aid. The perfect solution might be a better
version of nonzero_bits. Thanks.
diff --git a/gcc/co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93453
--- Comment #6 from HaoChen Gui ---
Sehger,
Yes, I found that the nonzero_bits doesn't return exact value in other pass.
So calling nonzero_bits in md file is bad as it can't be recognized in other
pass.
Right now I want to convert a single
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93453
--- Comment #4 from HaoChen Gui ---
For the second issue, I drafted following insn_and_split pattern. It tries to
combine the shift and ior when the nonzero_bits of operands[3] matches the
condition.
(define_insn_and_split "*rotl3_insert_8"
[
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103124
--- Comment #3 from HaoChen Gui ---
My solution is to split the move (from TI to V1TI) into one vsx_concat_v2di and
one V2DI to V1TI move. Thus, TI register 122 can be decomposed.
(insn 12 11 17 2 (set (reg:V1TI 121 [ b ])
(subreg:V1TI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93453
HaoChen Gui changed:
What|Removed |Added
CC||guihaoc at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103124
--- Comment #2 from HaoChen Gui ---
//lower-subreg.c
/* If this is a cast from one mode to another, where the modes
have the same size, and they are not tieable, then mark this
register as non-decomposable. I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103124
--- Comment #1 from HaoChen Gui ---
Build command gcc -O2 -S test.c -mcpu=power9
ty: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: guihaoc at gcc dot gnu.org
Target Milestone: ---
//test.c
vector __int128 init (long long a)
{
vector __int128 b;
b = (vector __int128) {a};
return b;
}
gcc -O2 -s te
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102169
HaoChen Gui changed:
What|Removed |Added
CC||guihaoc at gcc dot gnu.org
--- Comment
1 - 100 of 111 matches
Mail list logo
