public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
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

  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).