From: luoxhu <luoxhu@linux.ibm.com>
To: Richard Biener <richard.guenther@gmail.com>
Cc: Segher Boessenkool <segher@kernel.crashing.org>,
GCC Patches <gcc-patches@gcc.gnu.org>,
David Edelsohn <dje.gcc@gmail.com>,
Bill Schmidt <wschmidt@linux.ibm.com>,
linkw@gcc.gnu.org
Subject: Re: [PATCH v2] rs6000: Expand vec_insert in expander instead of gimple [PR79251]
Date: Wed, 16 Sep 2020 14:15:13 +0800 [thread overview]
Message-ID: <0fe933f6-1d54-086e-89b8-62717dd9340d@linux.ibm.com> (raw)
In-Reply-To: <CAFiYyc3a7v-3GL0rHijpautPiwq1z2qJuUWN7FDQEMOyp=yvJg@mail.gmail.com>
On 2020/9/15 14:51, Richard Biener wrote:
>> I only see VAR_DECL and PARM_DECL, is there any function to check the tree
>> variable is global? I added DECL_REGISTER, but the RTL still expands to stack:
>
> is_global_var () or alternatively !auto_var_in_fn_p (), I think doing
> IFN_SET only
> makes sense if there's the chance we can promote the variable to a
> register. But it
> would be an incorrect transform (it stores the whole vector) if the
> vector storage
> could "escape" to another thread - which means you probably have to check
> !TREE_ADDRESSABLE as well.
>
The tree of param "u" will be marked ADDRESSABLE when generating
"VIEW_CONVERT_EXPR<int[4]>(D.3190)[_1] = i;", if check !TREE_ADDRESSABLE, no IFN_SET
will be produced in gimple-isel.
#1 0x000000001066c700 in convert_vector_to_array_for_subscript (loc=5307072, vecp=0x7fffffffc5d0,
index=<trunc_mod_expr 0x7ffff59c73a0>) at ../../gcc/gcc/c-family/c-common.c:8169
#2 0x0000000010553b54 in build_array_ref (loc=5307072, array=<parm_decl 0x7ffff5ad0100 u>, index=<
trunc_mod_expr 0x7ffff59c73a0>) at ../../gcc/gcc/c/c-typeck.c:2668
#3 0x00000000105c8824 in c_parser_postfix_expression_after_primary (parser=0x7ffff7f703f0, expr_lo
c=5307040, expr=...) at ../../gcc/gcc/c/c-parser.c:10494
#4 0x00000000105c7570 in c_parser_postfix_expression (parser=0x7ffff7f703f0) at ../../gcc/gcc/c/c-
parser.c:10216
>>
>> My current implementation does:
>>
>> 1) v = vec_insert (i, u, n);
>>
>> =>gimple:
>> {
>> register __vector signed int D.3190;
>> D.3190 = u; // *new decl and copy u first.*
>> _1 = n & 3;
>> VIEW_CONVERT_EXPR<int[4]>(D.3190)[_1] = i; // *update op0 of VIEW_CONVERT_EXPR*
>> _2 = D.3190;
>> ...
>> }
>>
>> =>isel:
>> {
>> register __vector signed int D.3190;
>> D.3190 = u_4(D);
>> _1 = n_6(D) & 3;
>> .VEC_SET (&D.3190, i_7(D), _1);
>
> why are you passing the address of D.3190 to .VEC_SET? That will not
> make D.3190
> be expanded to a pseudo. You really need to have GIMPLE registers
> here (SSA name)
> and thus a return value, leaving the argument unmodified
>
> D.3190_3 = .VEC_SET (D.3190_4, i_7(D), _1);
>
> note this is why I asked about the actual CPU instruction - as I read
> Seghers mail
> the instruction modifies a vector register, not memory.
>
Updated the code and got expected gimple-isel output and ASM for both 2 cases:
pr79251.c.236t.isel:
__attribute__((noinline))
test (__vector signed int u, int i, size_t n)
{
long unsigned int _1;
__vector signed int _6;
vector(4) int _7;
vector(4) int vec_set_dst_8;
<bb 2> [local count: 1073741824]:
_1 = n_2(D) & 3;
_7 = u;
vec_set_dst_8 = .VEC_SET (_7, i_4(D), _1);
u = vec_set_dst_8;
_6 = u;
return _6;
}
But tree variable "u" need to be set to "TREE_ADDRESSABLE (view_op0) = 0;"
(Maybe check IFN VEC_SET and set to 0 in discover_nonconstant_array_refs
is better later.) after generating the IFN VEC_SET, otherwise, "u" will still
be expanded to stack since expander:
"Replacing Expressions: _7 replace with --> _7 = u;".
Setting "u" to non-addressable also seems really unreasonable as for below
case, as u[n+1] need be ADDRESSABLE:
__attribute__ ((noinline)) vector TYPE
test (vector TYPE u, TYPE i, size_t n)
{
u[n % 4] = i;
u[n+1] = i+1;
return u;
}
=> gimple-isel with both VEC_SET and VIEW_CONVERT_EXPR:
test (__vector signed int u, int i, size_t n)
{
long unsigned int _1;
long unsigned int _2;
int _3;
__vector signed int _9;
vector(4) int _10;
vector(4) int vec_set_dst_11;
<bb 2> [local count: 1073741824]:
_1 = n_4(D) & 3;
_10 = u;
vec_set_dst_11 = .VEC_SET (_10, i_6(D), _1);
u = vec_set_dst_11;
_2 = n_4(D) + 1;
_3 = i_6(D) + 1;
VIEW_CONVERT_EXPR<int[4]>(u)[_2] = _3;
_9 = u;
return _9;
}
Below code are generating the IFN call, create_tmp_reg or create_tmp_reg_ssa_name
seems not create a variable that will be allocated on register?
diff --git a/gcc/gimple-isel.cc b/gcc/gimple-isel.cc
index b330cf4c20e..a699022cd09 100644
--- a/gcc/gimple-isel.cc
+++ b/gcc/gimple-isel.cc
...
+ if (!is_global_var (view_op0)
+ && TREE_CODE (TREE_TYPE (view_op0)) == VECTOR_TYPE
+ && tree_fits_uhwi_p (TYPE_SIZE (TREE_TYPE (view_op0)))
+ && tree_to_uhwi (TYPE_SIZE (TREE_TYPE (view_op0))) == 128
+ && determine_value_range (pos, &minv, &maxv) == VR_RANGE
+ && wi::geu_p (minv, 0)
+ && wi::leu_p (maxv, (128 / GET_MODE_BITSIZE (innermode))))
+ {
+ location_t loc = gimple_location (stmt);
+ tree var_src = create_tmp_reg (TREE_TYPE (view_op0));
+ tree var_dst
+ = make_temp_ssa_name (TREE_TYPE (view_op0), NULL, "vec_set_dst");
+ TREE_ADDRESSABLE (view_op0) = 0;
+
+ ass_stmt = gimple_build_assign (var_src, view_op0);
+ gimple_set_location (ass_stmt, loc);
+ gsi_insert_before (gsi, ass_stmt, GSI_SAME_STMT);
+
+ new_stmt
+ = gimple_build_call_internal (IFN_VEC_SET, 3, var_src, val, pos);
+
+ gimple_call_set_lhs (new_stmt, var_dst);
+
+ gimple_set_location (new_stmt, loc);
+ gsi_insert_before (gsi, new_stmt, GSI_SAME_STMT);
+
+ ass_stmt = gimple_build_assign (view_op0, var_dst);
+
+ gimple_set_location (ass_stmt, loc);
+ gsi_insert_before (gsi, ass_stmt, GSI_SAME_STMT);
+
+ gimple_move_vops (ass_stmt, stmt);
+ }
+ }
+
+ return ass_stmt;
Thanks,
Xionghu
next prev parent reply other threads:[~2020-09-16 6:15 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-31 9:06 [PATCH] " Xiong Hu Luo
2020-08-31 12:43 ` Richard Biener
2020-08-31 16:47 ` will schmidt
2020-09-01 11:43 ` luoxhu
2020-08-31 17:04 ` Segher Boessenkool
2020-09-01 8:09 ` luoxhu
2020-09-01 13:07 ` Richard Biener
2020-09-02 9:26 ` luoxhu
2020-09-02 9:30 ` Richard Biener
2020-09-03 9:20 ` luoxhu
2020-09-03 10:29 ` Richard Biener
2020-09-04 6:16 ` luoxhu
2020-09-04 6:38 ` luoxhu
2020-09-04 7:19 ` Richard Biener
2020-09-04 7:23 ` Richard Biener
2020-09-04 9:18 ` luoxhu
2020-09-04 10:23 ` Segher Boessenkool
2020-09-07 5:43 ` [PATCH v2] " luoxhu
2020-09-07 11:57 ` Richard Biener
2020-09-08 8:11 ` luoxhu
2020-09-08 8:26 ` Richard Biener
2020-09-09 1:47 ` luoxhu
2020-09-09 7:30 ` Richard Biener
2020-09-09 13:47 ` Segher Boessenkool
2020-09-09 14:28 ` Richard Biener
2020-09-09 16:00 ` Segher Boessenkool
2020-09-10 10:08 ` Richard Biener
2020-09-14 8:05 ` luoxhu
2020-09-14 9:47 ` Richard Biener
2020-09-14 10:47 ` Richard Sandiford
2020-09-14 11:22 ` Richard Biener
2020-09-14 11:49 ` Richard Sandiford
2020-09-14 21:06 ` Segher Boessenkool
2020-09-14 20:59 ` Segher Boessenkool
2020-09-15 3:56 ` luoxhu
2020-09-15 6:51 ` Richard Biener
2020-09-15 16:16 ` Segher Boessenkool
2020-09-16 8:31 ` Richard Biener
2020-09-16 11:11 ` Segher Boessenkool
2020-09-16 6:15 ` luoxhu [this message]
2020-09-16 8:41 ` Richard Biener
2020-09-14 20:21 ` Segher Boessenkool
2020-09-01 14:02 ` [PATCH] " Segher Boessenkool
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0fe933f6-1d54-086e-89b8-62717dd9340d@linux.ibm.com \
--to=luoxhu@linux.ibm.com \
--cc=dje.gcc@gmail.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=linkw@gcc.gnu.org \
--cc=richard.guenther@gmail.com \
--cc=segher@kernel.crashing.org \
--cc=wschmidt@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).