Vectorization of loop which operate on local arrays
Hello,
I am working on gcc-4.9.4 and encountered different results of loop
vectorization on array arr0, arr1 and arr2.
Testcase -
int main()
{
int i;
for (i=0; i<64; i++)
{
arr2[i]=(arr1[i]|arr0[i]);
}
}
Using -O2 -ftree-vectorize, Above loop is vectorized if arr0, arr1,
arr2 are global arrays whereas if they are local, loop is not getting
vectorized.
1. Is there any flag which will enable vectorization of loop which
will operate on local array as well?
2. Which part of code I need to tweak so that I would get
vectorization on loops operating on local arrays or at least know why
vectorization is not suggested for such loops?
Thanks and Regards
Shubham
Re: Get struct function* from function declaration
On Tue, 16 Feb, 2021, 5:55 PM Shuai Wang via Gcc, wrote: > Thank you for your reply! > > I tried to use this in the following code: > > tree func_decl = gimple_call_fndecl(stmt); // stmt is the function call > statement > function* f = DECL_STRUCT_FUNCTION(func_decl); > std::cerr << get_name(f->decl) << std::endl; > > However, it seems the last line throws an exception as follows: > > during GIMPLE pass: XXX // here XXX is my pass name > internal compiler error: Segmentation fault > Hi, Check whether f is a valid function pointer or not. It seems the function is inlined. You can verify it with -fno-inline. Macros defined in tree.h are helpful to get a broader view of the problem. Shubham ... > > That seems strange. Does that seem familiar to you by any chance? Thank > you! > > Best, > Shuai > > > > On Tue, Feb 16, 2021 at 7:52 PM Martin Liška wrote: > > > On 2/16/21 9:51 AM, Shuai Wang via Gcc wrote: > > > However, can I proceed further to get the function* of "foo"? I checked > > > > Hello. > > > > Yes, you can call DECL_STRUCT_FUNCTION(func_decl). > > > > Martin > > >
Extracting function name from the gimple call statement
Hello,
Is there a direct way to print the name of the function call in gimple call
statement?
For example -
void bar() {
a = foo();//gimple* stmt
}
I want to print "foo" from the above gimple*.
I traced debug_gimple_stmt(gimple*) but it seems complex to just print
"foo".
Thanks and Regards,
Shubham
Re: Extracting function name from the gimple call statement
On Mon, Oct 11, 2021 at 2:51 AM David Malcolm wrote:
>
> On Sun, 2021-10-10 at 23:04 +0530, Shubham Narlawar via Gcc wrote:
> > Hello,
> >
> > Is there a direct way to print the name of the function call in gimple
> > call
> > statement?
> >
> > For example -
> >
> > void bar() {
> > a = foo();//gimple* stmt
> > }
> >
> > I want to print "foo" from the above gimple*.
> >
> > I traced debug_gimple_stmt(gimple*) but it seems complex to just print
> > "foo".
>
> Bear in mind that not every gimple call is calling a specific function;
> it could be a jump through a function pointer.
>
> tree fn_ptr = gimple_call_fn (call);
>
> However, for simple cases like the above, fn_ptr will be an ADDR_EXPR
> node, and the zeroth operand of the ADDR_EXPR node will get you the
> fndecl (of "foo").
> tree fn_decl = TREE_OPERAND (fn_ptr, 0);
>
> Given a decl, you can then use:
> tree identifier = DECL_NAME (fn_decl);
> to get the identifier node for the decl ("foo").
>
> Finally, you can use
> const char *str = IDENTIFIER_POINTER (identifier)
> to get a 0-terminated string from the identifier that you can print.
>
> Hope this is helpful
This is helpful! Thank you David for the detailed explanation. This is
exactly what I was looking for. Now, I am able to get the function
name using above checks.
Regards,
Shubham
> Dave
>
Updating phi nodes on deleting gimple statement
Hello, I have a PHI node that defines a variable that is used in 1 statement. I then delete the statement. I think I need to update the PHI node to no longer reference that variable. I looked through some code and I don't see a way to just remove an element from a PHI node and I see in the file omp-expand.c what looks like creating a new PHI node and copying over all of the elements. My question is: how do I update a PHI node per the above? Is it necessary - if I don't do anything and leave the PHI node as is it appears to work, though I don't know the implications of this. If I do need to update it, do I recreate it and delete the old one? Thanks and Regards, Shubham
Re: Updating phi nodes on deleting gimple statement
On Thu, 16 Dec, 2021, 6:28 pm Richard Biener, wrote: > On December 16, 2021 7:33:37 AM GMT+01:00, Shubham Narlawar via Gcc < > gcc@gcc.gnu.org> wrote: > >Hello, > > > > > >I have a PHI node that defines a variable that is used in 1 statement. I > >then delete the statement. I think I need to update the PHI node to no > >longer reference that variable. I looked through some code and I don't see > >a way to just remove an element from a PHI node and I see in the file > >omp-expand.c what looks like creating a new PHI node and copying over all > >of the elements. > > > >My question is: how do I update a PHI node per the above? Is it necessary > - > >if I don't do anything and leave the PHI node as is it appears to work, > >though I don't know the implications of this. If I do need to update it, > do > >I recreate it and delete the old one? > > You don't need to do anything to the PHI node. > Understood! Thanks and Regards, Shubham > Richard. > > >Thanks and Regards, > >Shubham > >
Accessing const parameter of GIMPLE_CALL
Hello,
My aim is to iterate over gimple call stmt parameters and check
whether it is constant or constant expression and mark/store them for
some gimple transformation.
I have an intrinsic function call of the following -
__builtin_xyz(void*, 7, addr + 10);
I want to find its parameters which are either constant or constant
expression i.e. 7 and addr + 10 from above case.
[1] I tried below macro but there is very less usage in the entire source code -
tree fn_ptr = gimple_call_fn (dyn_cast (stmt));//stmt
= gimple_call
function_args_iterator iter;
tree argtype;
if (TREE_CODE (fn_ptr) == ADDR_EXPR)
{
FOREACH_FUNCTION_ARGS (fn_ptr, argtype, iter)
{
if (TREE_CONSTANT (argtype))
// Found a constant expression parameter
}
}
The problem is I am getting only one parameter tree but there are 2
constants in the above function call. Even if "addr + 10" is treated
differently, I want to mark it for the transformation.
a. Is the above correct method to iterate over function call parameters?
b. Is there a different way to achieve the above goal?
Thanks and Regards,
Shubham
Re: Accessing const parameter of GIMPLE_CALL
On Mon, Jan 17, 2022 at 5:23 AM David Malcolm wrote:
>
> On Sun, 2022-01-16 at 18:52 +0530, Shubham Narlawar via Gcc wrote:
> > Hello,
>
> Hi; various notes inline below...
>
> >
> > My aim is to iterate over gimple call stmt parameters and check
> > whether it is constant or constant expression and mark/store them for
> > some gimple transformation.
> >
> > I have an intrinsic function call of the following -
> >
> > __builtin_xyz(void*, 7, addr + 10);
> >
> > I want to find its parameters which are either constant or constant
> > expression i.e. 7 and addr + 10 from above case.
>
> Gimple "flattens" all tree-like operations into a sequence of simple
> operations, so I would expect the gimple for this to look something
> like this:
>
>_tmp = addr + 10;
>__builtin_xyx (7, _tmp);
Hi David,
Yeah. Correct.
>
> Your email doesn't specify *when* your code runs.
>
> The IR for a function goes through several stages:
>
> - an initial gimple IR without a CFG
> - gimple with a CFG, but not in SSA
> - gimple-SSA with a CFG
> (most of the gimple optimization passes operate in this form of the
> IR)
> - gimple with a CFG, but no longer in CFG form, immediately before
> conversion to RTL-with-CFG form
> - RTL-with-CFG
> - RTL-without a CFG
> - assembler
>
> Are you doing it as part of a plugin, or modifying an existing pass?
> In either case, it's a good idea to dump the gimple and see what the
> code has been turned into. You'll probably find the following options
> useful:
> -fdump-tree-all -fdump-gimple-all
>
> or alternatively just turn it on for the pass that you're working on.
I am doing it as a plugin and it is placed just after
"pass_build_cgraph_edges" i.e. Call Graph Construction.
>
> >
> > [1] I tried below macro but there is very less usage in the entire
> > source code -
> >
> > tree fn_ptr = gimple_call_fn (dyn_cast (stmt));//stmt
>
> gimple_call_fn returns the function that will be called, a pointer.
> This is very general, for handling things like jumps through function
> pointers, but here you have the common case of a callsite that calls a
> specific function, so "fn_ptr" here is:
>&__builtin_xyx
> i.e. an ADDR_EXPR where operand 0 is the FUNCTION_DECL for the builtin.
Got it.
>
> > = gimple_call
> > function_args_iterator iter;
> > tree argtype;
> >
> > if (TREE_CODE (fn_ptr) == ADDR_EXPR)
> > {
> > FOREACH_FUNCTION_ARGS (fn_ptr, argtype, iter)
>
> Looking in tree.h, FOREACH_FUNCTION_ARGS takes a FUNCTION_TYPE as its
> first argument, but the code above is passing it the ADDR_EXPR wrapping
> the FUNCTION_DECL.
Understood.
>
> Unfortunately, because these things are all of type "tree", this kind
> of type mismatch doesn't get caught - unless you build gcc from source
> (with --enable-checking=debug) in which case all these accesses are
> checked at the compiler's run time (which is probably a good thing to
> do if you're hoping to work on gcc for GSoC).
I am working on gcc version 10.2.0 and there is no such flag as
"--enable-checking" but there is "--enable-gcc-checking".
>
> You can get the FUNCTION_TYPE of a FUNCTION_DECL via TREE_TYPE
> (fndecl), or alternatively, gimple_call_fntype (call) will get the type
> of the function expected at the call stmt (useful if there was a type
> mismatch).
>
> That said, FOREACH_FUNCTION_ARGS iterates through the types of the
> params of the FUNCTION_TYPE, but it sounds like you want to be
> iterating through the arguments at this particular *callsite*.
>
> For that you can use
> gimple_call_num_args (call);
> and
> gimple_call_arg (call, idx);
Yes. This is exactly what I was looking for!
>
> > {
> > if (TREE_CONSTANT (argtype))
> >// Found a constant expression parameter
> > }
> > }
> >
> > The problem is I am getting only one parameter tree but there are 2
> > constants in the above function call. Even if "addr + 10" is treated
> > differently, I want to mark it for the transformation.
>
> I think you're seeing the function pointer being called, ather than the
> params.
Yes.
>
> >
> > a. Is the above correct method to iterate over function call
> > parameters?
>
> As noted above, it depends on whether you want to iterate over the
> types of the parameters in the function's decl, or over the expressions
> of the arguments at the callsite. I believe the above explains how to
> do each of these.
Yes. Above clears all my queries a
Re: Accessing const parameter of GIMPLE_CALL
On Mon, Jan 17, 2022 at 1:55 PM Richard Biener
wrote:
>
> On Mon, Jan 17, 2022 at 12:54 AM David Malcolm via Gcc
> wrote:
> >
> > On Sun, 2022-01-16 at 18:52 +0530, Shubham Narlawar via Gcc wrote:
> > > Hello,
> >
> > Hi; various notes inline below...
> >
> > >
> > > My aim is to iterate over gimple call stmt parameters and check
> > > whether it is constant or constant expression and mark/store them for
> > > some gimple transformation.
> > >
> > > I have an intrinsic function call of the following -
> > >
> > > __builtin_xyz(void*, 7, addr + 10);
> > >
> > > I want to find its parameters which are either constant or constant
> > > expression i.e. 7 and addr + 10 from above case.
> >
> > Gimple "flattens" all tree-like operations into a sequence of simple
> > operations, so I would expect the gimple for this to look something
> > like this:
> >
> >_tmp = addr + 10;
> >__builtin_xyx (7, _tmp);
> >
> > Your email doesn't specify *when* your code runs.
> >
> > The IR for a function goes through several stages:
> >
> > - an initial gimple IR without a CFG
> > - gimple with a CFG, but not in SSA
> > - gimple-SSA with a CFG
> > (most of the gimple optimization passes operate in this form of the
> > IR)
> > - gimple with a CFG, but no longer in CFG form, immediately before
> > conversion to RTL-with-CFG form
> > - RTL-with-CFG
> > - RTL-without a CFG
> > - assembler
> >
> > Are you doing it as part of a plugin, or modifying an existing pass?
> > In either case, it's a good idea to dump the gimple and see what the
> > code has been turned into. You'll probably find the following options
> > useful:
> > -fdump-tree-all -fdump-gimple-all
> >
> > or alternatively just turn it on for the pass that you're working on.
> >
> > >
> > > [1] I tried below macro but there is very less usage in the entire
> > > source code -
> > >
> > > tree fn_ptr = gimple_call_fn (dyn_cast (stmt));//stmt
> >
> > gimple_call_fn returns the function that will be called, a pointer.
> > This is very general, for handling things like jumps through function
> > pointers, but here you have the common case of a callsite that calls a
> > specific function, so "fn_ptr" here is:
> >&__builtin_xyx
> > i.e. an ADDR_EXPR where operand 0 is the FUNCTION_DECL for the builtin.
> >
> > > = gimple_call
> > > function_args_iterator iter;
> > > tree argtype;
> > >
> > > if (TREE_CODE (fn_ptr) == ADDR_EXPR)
> > > {
> > > FOREACH_FUNCTION_ARGS (fn_ptr, argtype, iter)
> >
> > Looking in tree.h, FOREACH_FUNCTION_ARGS takes a FUNCTION_TYPE as its
> > first argument, but the code above is passing it the ADDR_EXPR wrapping
> > the FUNCTION_DECL.
> >
> > Unfortunately, because these things are all of type "tree", this kind
> > of type mismatch doesn't get caught - unless you build gcc from source
> > (with --enable-checking=debug) in which case all these accesses are
> > checked at the compiler's run time (which is probably a good thing to
> > do if you're hoping to work on gcc for GSoC).
> >
> > You can get the FUNCTION_TYPE of a FUNCTION_DECL via TREE_TYPE
> > (fndecl), or alternatively, gimple_call_fntype (call) will get the type
> > of the function expected at the call stmt (useful if there was a type
> > mismatch).
> >
> > That said, FOREACH_FUNCTION_ARGS iterates through the types of the
> > params of the FUNCTION_TYPE, but it sounds like you want to be
> > iterating through the arguments at this particular *callsite*.
> >
> > For that you can use
> > gimple_call_num_args (call);
> > and
> > gimple_call_arg (call, idx);
> >
> > > {
> > > if (TREE_CONSTANT (argtype))
> > >// Found a constant expression parameter
> > > }
> > > }
> > >
> > > The problem is I am getting only one parameter tree but there are 2
> > > constants in the above function call. Even if "addr + 10" is treated
> > > differently, I want to mark it for the transformation.
> >
> > I think you're seeing the function pointer being called, ather than the
> > params.
>
> I think you are iterating over the functions formal argument types
> rather than a specific call parameters. To look at the actual
> parameters us
Re: Accessing const parameter of GIMPLE_CALL
On Tue, Jan 18, 2022 at 2:19 AM Martin Sebor wrote:
>
> On 1/17/22 12:18, Shubham Narlawar via Gcc wrote:
> > On Mon, Jan 17, 2022 at 1:55 PM Richard Biener
> > wrote:
> >>
> >> On Mon, Jan 17, 2022 at 12:54 AM David Malcolm via Gcc
> >> wrote:
> >>>
> >>> On Sun, 2022-01-16 at 18:52 +0530, Shubham Narlawar via Gcc wrote:
> >>>> Hello,
> >>>
> >>> Hi; various notes inline below...
> >>>
> >>>>
> >>>> My aim is to iterate over gimple call stmt parameters and check
> >>>> whether it is constant or constant expression and mark/store them for
> >>>> some gimple transformation.
> >>>>
> >>>> I have an intrinsic function call of the following -
> >>>>
> >>>> __builtin_xyz(void*, 7, addr + 10);
> >>>>
> >>>> I want to find its parameters which are either constant or constant
> >>>> expression i.e. 7 and addr + 10 from above case.
> >>>
> >>> Gimple "flattens" all tree-like operations into a sequence of simple
> >>> operations, so I would expect the gimple for this to look something
> >>> like this:
> >>>
> >>> _tmp = addr + 10;
> >>> __builtin_xyx (7, _tmp);
> >>>
> >>> Your email doesn't specify *when* your code runs.
> >>>
> >>> The IR for a function goes through several stages:
> >>>
> >>> - an initial gimple IR without a CFG
> >>> - gimple with a CFG, but not in SSA
> >>> - gimple-SSA with a CFG
> >>>(most of the gimple optimization passes operate in this form of the
> >>> IR)
> >>> - gimple with a CFG, but no longer in CFG form, immediately before
> >>> conversion to RTL-with-CFG form
> >>> - RTL-with-CFG
> >>> - RTL-without a CFG
> >>> - assembler
> >>>
> >>> Are you doing it as part of a plugin, or modifying an existing pass?
> >>> In either case, it's a good idea to dump the gimple and see what the
> >>> code has been turned into. You'll probably find the following options
> >>> useful:
> >>>-fdump-tree-all -fdump-gimple-all
> >>>
> >>> or alternatively just turn it on for the pass that you're working on.
> >>>
> >>>>
> >>>> [1] I tried below macro but there is very less usage in the entire
> >>>> source code -
> >>>>
> >>>> tree fn_ptr = gimple_call_fn (dyn_cast (stmt));//stmt
> >>>
> >>> gimple_call_fn returns the function that will be called, a pointer.
> >>> This is very general, for handling things like jumps through function
> >>> pointers, but here you have the common case of a callsite that calls a
> >>> specific function, so "fn_ptr" here is:
> >>> &__builtin_xyx
> >>> i.e. an ADDR_EXPR where operand 0 is the FUNCTION_DECL for the builtin.
> >>>
> >>>> = gimple_call
> >>>> function_args_iterator iter;
> >>>> tree argtype;
> >>>>
> >>>> if (TREE_CODE (fn_ptr) == ADDR_EXPR)
> >>>> {
> >>>>FOREACH_FUNCTION_ARGS (fn_ptr, argtype, iter)
> >>>
> >>> Looking in tree.h, FOREACH_FUNCTION_ARGS takes a FUNCTION_TYPE as its
> >>> first argument, but the code above is passing it the ADDR_EXPR wrapping
> >>> the FUNCTION_DECL.
> >>>
> >>> Unfortunately, because these things are all of type "tree", this kind
> >>> of type mismatch doesn't get caught - unless you build gcc from source
> >>> (with --enable-checking=debug) in which case all these accesses are
> >>> checked at the compiler's run time (which is probably a good thing to
> >>> do if you're hoping to work on gcc for GSoC).
> >>>
> >>> You can get the FUNCTION_TYPE of a FUNCTION_DECL via TREE_TYPE
> >>> (fndecl), or alternatively, gimple_call_fntype (call) will get the type
> >>> of the function expected at the call stmt (useful if there was a type
> >>> mismatch).
> >>>
> >>> That said, FOREACH_FUNCTION_ARGS iterates through the types of the
> >>> params of the FUNCTION_TYPE, but it sounds like you want to be
> >>> iterating through the arguments at this particular *callsite*.
> >&
Re: Accessing const parameter of GIMPLE_CALL
On Tue, Jan 18, 2022 at 2:20 PM Richard Biener
wrote:
>
> On Mon, Jan 17, 2022 at 8:19 PM Shubham Narlawar
> wrote:
> >
> > On Mon, Jan 17, 2022 at 1:55 PM Richard Biener
> > wrote:
> > >
> > > On Mon, Jan 17, 2022 at 12:54 AM David Malcolm via Gcc
> > > wrote:
> > > >
> > > > On Sun, 2022-01-16 at 18:52 +0530, Shubham Narlawar via Gcc wrote:
> > > > > Hello,
> > > >
> > > > Hi; various notes inline below...
> > > >
> > > > >
> > > > > My aim is to iterate over gimple call stmt parameters and check
> > > > > whether it is constant or constant expression and mark/store them for
> > > > > some gimple transformation.
> > > > >
> > > > > I have an intrinsic function call of the following -
> > > > >
> > > > > __builtin_xyz(void*, 7, addr + 10);
> > > > >
> > > > > I want to find its parameters which are either constant or constant
> > > > > expression i.e. 7 and addr + 10 from above case.
> > > >
> > > > Gimple "flattens" all tree-like operations into a sequence of simple
> > > > operations, so I would expect the gimple for this to look something
> > > > like this:
> > > >
> > > >_tmp = addr + 10;
> > > >__builtin_xyx (7, _tmp);
> > > >
> > > > Your email doesn't specify *when* your code runs.
> > > >
> > > > The IR for a function goes through several stages:
> > > >
> > > > - an initial gimple IR without a CFG
> > > > - gimple with a CFG, but not in SSA
> > > > - gimple-SSA with a CFG
> > > > (most of the gimple optimization passes operate in this form of the
> > > > IR)
> > > > - gimple with a CFG, but no longer in CFG form, immediately before
> > > > conversion to RTL-with-CFG form
> > > > - RTL-with-CFG
> > > > - RTL-without a CFG
> > > > - assembler
> > > >
> > > > Are you doing it as part of a plugin, or modifying an existing pass?
> > > > In either case, it's a good idea to dump the gimple and see what the
> > > > code has been turned into. You'll probably find the following options
> > > > useful:
> > > > -fdump-tree-all -fdump-gimple-all
> > > >
> > > > or alternatively just turn it on for the pass that you're working on.
> > > >
> > > > >
> > > > > [1] I tried below macro but there is very less usage in the entire
> > > > > source code -
> > > > >
> > > > > tree fn_ptr = gimple_call_fn (dyn_cast (stmt));//stmt
> > > >
> > > > gimple_call_fn returns the function that will be called, a pointer.
> > > > This is very general, for handling things like jumps through function
> > > > pointers, but here you have the common case of a callsite that calls a
> > > > specific function, so "fn_ptr" here is:
> > > >&__builtin_xyx
> > > > i.e. an ADDR_EXPR where operand 0 is the FUNCTION_DECL for the builtin.
> > > >
> > > > > = gimple_call
> > > > > function_args_iterator iter;
> > > > > tree argtype;
> > > > >
> > > > > if (TREE_CODE (fn_ptr) == ADDR_EXPR)
> > > > > {
> > > > > FOREACH_FUNCTION_ARGS (fn_ptr, argtype, iter)
> > > >
> > > > Looking in tree.h, FOREACH_FUNCTION_ARGS takes a FUNCTION_TYPE as its
> > > > first argument, but the code above is passing it the ADDR_EXPR wrapping
> > > > the FUNCTION_DECL.
> > > >
> > > > Unfortunately, because these things are all of type "tree", this kind
> > > > of type mismatch doesn't get caught - unless you build gcc from source
> > > > (with --enable-checking=debug) in which case all these accesses are
> > > > checked at the compiler's run time (which is probably a good thing to
> > > > do if you're hoping to work on gcc for GSoC).
> > > >
> > > > You can get the FUNCTION_TYPE of a FUNCTION_DECL via TREE_TYPE
> > > > (fndecl), or alternatively, gimple_call_fntype (call) will get the type
> > > > of the function expected at the call stmt (useful if there was a type
> > > > mismatch).
> > > >
> > > > That said, FOREACH_FUNCTION_ARGS iterates th
Query regarding generating NOTE instruction at GIMPLE level
Hello, Is it possible to generate a NOTE instruction at GIMPLE level? My use case scenario is as below - I want to create a note for __builtin_xyz(_x) such that there is a placeholder just before function call and in RTL pass, I want to modify/assign register number at this placeholder location. _x = (unsigned int) _y; __builtin_xyz(_x);//_x is constant expression For above builtin function call, I want to insert a note just before the function call. I tried generating GIMPLE_NOP instruction as below - _x = (unsigned int) _y; GIMPLE_NOP __builtin_xyz(_x); But as per my understanding, a NOTE instruction behaves similar to GIMPLE_NOP that is to create a placeholder for some computation. 1. Is there any attribute that can be added to GIMPLE instruction? If yes, then there must be a mechanism that translates those attributes to NOTE instructions in the RTL pass? 2. Is there any different approach on achieving above goal? Thanks and Regards, Shubham
Validation of adding left shift stmt at GIMPLE - [Custom GCC plugin]]
Hello, I want to know whether it is correct to add left shift instruction to a constant expression statement like "_3 + 4"? I am trying to add a left shift instruction in between below GIMPLE instructions - : instrn_buffer.0_1 = instrn_buffer; _2 = tree.cnt; _3 = (int) _2; _4 = _3 + 4; _5 = (unsigned int) _4;// I want to add left shift here D.2993 = __builtin_riscv_sfploadi (instrn_buffer.0_1, 0, _5); //this is "stmt" I am using this snippet in custom gcc plugin - tree lshift_tmp = make_temp_ssa_name (integer_type_node, NULL, "slli"); gimple *lshift = gimple_build_assign (lshift_tmp, LSHIFT_EXPR, parm, build_int_cst (integer_type_node, 8)); gsi_insert_before(&gsi, lshift, GSI_NEW_STMT); //Update function call gimple_call_set_arg (stmt, idx, lshift_tmp); update_stmt (stmt); update_ssa (TODO_update_ssa); from which above GIMPLE IR is modified to - : instrn_buffer.0_1 = instrn_buffer; _2 = tree.cnt; _3 = (int) _2; _4 = _3 + 4; _5 = (unsigned int) _4; slli_24 = _5 << 8; D.2993 = __builtin_riscv_sfploadi (instrn_buffer.0_1, 0, slli_24); 1. When I run above code, either dominator tree validation or tree cfg fixup is failing which suggests to me it is either incorrect to apply such left shift or some more work is missing? 2. I followed how a left shift gimple assignment is generated but still feels there is something wrong with the above generation. Can someone please point me out? Thanks in advance! As always, the GCC community and its members are very supportive, responsive and helpful! Regards, Shubham
Re: Validation of adding left shift stmt at GIMPLE - [Custom GCC plugin]]
On Sat, Feb 19, 2022 at 1:15 AM Andrew Pinski wrote: > > On Fri, Feb 18, 2022 at 11:04 AM Shubham Narlawar via Gcc > wrote: > > > > Hello, > > > > I want to know whether it is correct to add left shift instruction to > > a constant expression statement like "_3 + 4"? > > > > I am trying to add a left shift instruction in between below GIMPLE > > instructions - > > > >: > > instrn_buffer.0_1 = instrn_buffer; > > _2 = tree.cnt; > > _3 = (int) _2; > > _4 = _3 + 4; > > _5 = (unsigned int) _4;// I want to add left shift here > > D.2993 = __builtin_riscv_sfploadi (instrn_buffer.0_1, 0, _5); > > //this is "stmt" > > > > I am using this snippet in custom gcc plugin - > > > > tree lshift_tmp = make_temp_ssa_name (integer_type_node, > > NULL, "slli"); > > A couple of things. > I Noticed you use integer_type_node here. Why not the type of what is > being replaced? > That is the main thing I see right now. I want to apply left shift to a constant expression with 8 which is an integer. Since I am not replacing a statement, I am creating new GIMPLE statement - tree shift_amt = build_int_cst (integer_type_node, 8); Here, I am not replacing any GIMPLE statement. Is this the correct way to do this? My goal is to left shift constant expression and update its usage as below - _19 = (unsigned int) _18; D.2996 = __builtin_riscv_sfploadi (lexer.5_16, 12, _19); into _19 = (unsigned int) _18; temp = _19 << 8 D.2996 = __builtin_riscv_sfploadi (lexer.5_16, 12, temp); I am storing the left shift result to the new ssa variable name "temp" and updating sfploadi parameters as expected. On doing the above, dom_walker_eliminate is prohibiting me to do the above gimple transformation. Is the above transformation complete and correct? > > Also you shouldn't need to do: > update_ssa (TODO_update_ssa); > > As make_temp_ssa_name is a new SSA name already and such. Understood. Thanks and Regards, Shubham > > Thanks, > Andrew Pinski > > > gimple *lshift = gimple_build_assign (lshift_tmp, LSHIFT_EXPR, > > parm, > > build_int_cst > > (integer_type_node, 8)); > > gsi_insert_before(&gsi, lshift, GSI_NEW_STMT); > > //Update function call > > gimple_call_set_arg (stmt, idx, lshift_tmp); > > update_stmt (stmt); > > update_ssa (TODO_update_ssa); > > > > from which above GIMPLE IR is modified to - > > > >: > > instrn_buffer.0_1 = instrn_buffer; > > _2 = tree.cnt; > > _3 = (int) _2; > > _4 = _3 + 4; > > _5 = (unsigned int) _4; > > slli_24 = _5 << 8; > > D.2993 = __builtin_riscv_sfploadi (instrn_buffer.0_1, 0, slli_24); > > > > > > 1. When I run above code, either dominator tree validation or tree cfg > > fixup is failing which suggests to me it is either incorrect to apply > > such left shift or some more work is missing? > > > > 2. I followed how a left shift gimple assignment is generated but > > still feels there is something wrong with the above generation. Can > > someone please point me out? > > > > Thanks in advance! As always, the GCC community and its members are > > very supportive, responsive and helpful! > > > > Regards, > > Shubham
Re: Validation of adding left shift stmt at GIMPLE - [Custom GCC plugin]]
On Mon, Feb 21, 2022 at 1:02 PM Richard Biener
wrote:
>
> On Sun, Feb 20, 2022 at 11:44 PM Andrew Pinski via Gcc
> wrote:
> >
> > On Sun, Feb 20, 2022 at 10:45 AM Shubham Narlawar
> > wrote:
> > >
> > > On Sat, Feb 19, 2022 at 1:15 AM Andrew Pinski wrote:
> > > >
> > > > On Fri, Feb 18, 2022 at 11:04 AM Shubham Narlawar via Gcc
> > > > wrote:
> > > > >
> > > > > Hello,
> > > > >
> > > > > I want to know whether it is correct to add left shift instruction to
> > > > > a constant expression statement like "_3 + 4"?
> > > > >
> > > > > I am trying to add a left shift instruction in between below GIMPLE
> > > > > instructions -
> > > > >
> > > > >:
> > > > > instrn_buffer.0_1 = instrn_buffer;
> > > > > _2 = tree.cnt;
> > > > > _3 = (int) _2;
> > > > > _4 = _3 + 4;
> > > > > _5 = (unsigned int) _4;// I want to add left shift here
> > > > > D.2993 = __builtin_riscv_sfploadi (instrn_buffer.0_1, 0, _5);
> > > > > //this is "stmt"
> > > > >
> > > > > I am using this snippet in custom gcc plugin -
> > > > >
> > > > > tree lshift_tmp = make_temp_ssa_name (integer_type_node,
> > > > > NULL, "slli");
> > > >
> > > > A couple of things.
> > > > I Noticed you use integer_type_node here. Why not the type of what is
> > > > being replaced?
> > > > That is the main thing I see right now.
> > >
> > > I want to apply left shift to a constant expression with 8 which is an
> > > integer. Since I am not replacing a statement, I am creating new
> > > GIMPLE statement -
> > >
> > > tree shift_amt = build_int_cst (integer_type_node, 8);
> > >
> > > Here, I am not replacing any GIMPLE statement. Is this the correct way
> > > to do this?
> > >
> > > My goal is to left shift constant expression and update its usage as
> > > below -
> > >
> > > _19 = (unsigned int) _18;
> > > D.2996 = __builtin_riscv_sfploadi (lexer.5_16, 12, _19);
> > >
> > > into
> > >
> > > _19 = (unsigned int) _18;
> > > temp = _19 << 8
> > > D.2996 = __builtin_riscv_sfploadi (lexer.5_16, 12, temp);
> > >
> > > I am storing the left shift result to the new ssa variable name "temp"
> > > and updating sfploadi parameters as expected.
> > >
> > > On doing the above, dom_walker_eliminate is prohibiting me to do the
> > > above gimple transformation. Is the above transformation complete and
> > > correct?
> >
> > I think you misunderstood me. I was saying for a left shift gimple,
> > the result type and the first operand type must be compatible (signed
> > and unsigned types are not compatible). In the above case, you have:
> > integer_type_node = unsigned_int << integer_type_name .
> >
> > Does that make sense now?
>
> Btw, the error you see is still odd - please make sure to build GCC with
> checking enabled or run your tests with -fchecking. For further help
Sure.
> it might be useful to post the patch you are testing to show where exactly
> you are hooking into to add this statement.
My goal is to transform below IR -
_5 = (unsigned int) _4;
D.2993 = __builtin_riscv_* (instrn_buffer.0_1, 0, _5);
to target IR -
_5 = (unsigned int) _4;
lshiftamt_27 = _5 << 8;
D.2996 = __builtin_riscv_* (instrn_buffer.0_1, 0, lshiftamt_27);
I have followed this approach to build a new GIMPLE left shift
instruction -
https://github.com/gcc-mirror/gcc/blob/0435b978f95971e139882549f5a1765c50682216/gcc/ubsan.cc#L1257
Here is the patch which I am using -
--Patch---
unsigned int
pass_custom_lowering::execute (function *fun)
{
/* Code for iterating over all statements of function to find
function call of form - __builtin*
where one of parameter is constant expression of type "7 +
expression" i.e. 7 + _8
:
instrn_buffer.0_1 = instrn_buffer;
_2 = tree.cnt;
_3 = (int) _2;
_4 = _3 + 4;
_5 = (unsigned int) _4;// I want to apply left shift to _5
D.2993 = __builtin_riscv_* (instrn_buffer.0_1, 0, _5);
*/
gcall *stmt = dyn_cast (g); //here g is
__builtin_riscv_* where one of parameter is "_3 + 4"
tree parm = gimple_call_arg (stmt, 2);
Re: Validation of adding left shift stmt at GIMPLE - [Custom GCC plugin]]
On Tue, Feb 22, 2022 at 3:55 PM Richard Biener wrote: > > On Tue, Feb 22, 2022 at 8:38 AM Shubham Narlawar > wrote: > > > > On Mon, Feb 21, 2022 at 1:02 PM Richard Biener > > wrote: > > > > > > On Sun, Feb 20, 2022 at 11:44 PM Andrew Pinski via Gcc > > > wrote: > > > > > > > > On Sun, Feb 20, 2022 at 10:45 AM Shubham Narlawar > > > > wrote: > > > > > > > > > > On Sat, Feb 19, 2022 at 1:15 AM Andrew Pinski > > > > > wrote: > > > > > > > > > > > > On Fri, Feb 18, 2022 at 11:04 AM Shubham Narlawar via Gcc > > > > > > wrote: > > > > > > > > > > > > > > Hello, > > > > > > > > > > > > > > I want to know whether it is correct to add left shift > > > > > > > instruction to > > > > > > > a constant expression statement like "_3 + 4"? > > > > > > > > > > > > > > I am trying to add a left shift instruction in between below > > > > > > > GIMPLE > > > > > > > instructions - > > > > > > > > > > > > > >: > > > > > > > instrn_buffer.0_1 = instrn_buffer; > > > > > > > _2 = tree.cnt; > > > > > > > _3 = (int) _2; > > > > > > > _4 = _3 + 4; > > > > > > > _5 = (unsigned int) _4;// I want to add left shift here > > > > > > > D.2993 = __builtin_riscv_sfploadi (instrn_buffer.0_1, 0, _5); > > > > > > > //this is "stmt" > > > > > > > > > > > > > > I am using this snippet in custom gcc plugin - > > > > > > > > > > > > > > tree lshift_tmp = make_temp_ssa_name (integer_type_node, > > > > > > > NULL, "slli"); > > > > > > > > > > > > A couple of things. > > > > > > I Noticed you use integer_type_node here. Why not the type of what > > > > > > is > > > > > > being replaced? > > > > > > That is the main thing I see right now. > > > > > > > > > > I want to apply left shift to a constant expression with 8 which is an > > > > > integer. Since I am not replacing a statement, I am creating new > > > > > GIMPLE statement - > > > > > > > > > > tree shift_amt = build_int_cst (integer_type_node, 8); > > > > > > > > > > Here, I am not replacing any GIMPLE statement. Is this the correct way > > > > > to do this? > > > > > > > > > > My goal is to left shift constant expression and update its usage as > > > > > below - > > > > > > > > > > _19 = (unsigned int) _18; > > > > > D.2996 = __builtin_riscv_sfploadi (lexer.5_16, 12, _19); > > > > > > > > > > into > > > > > > > > > > _19 = (unsigned int) _18; > > > > > temp = _19 << 8 > > > > > D.2996 = __builtin_riscv_sfploadi (lexer.5_16, 12, temp); > > > > > > > > > > I am storing the left shift result to the new ssa variable name "temp" > > > > > and updating sfploadi parameters as expected. > > > > > > > > > > On doing the above, dom_walker_eliminate is prohibiting me to do the > > > > > above gimple transformation. Is the above transformation complete and > > > > > correct? > > > > > > > > I think you misunderstood me. I was saying for a left shift gimple, > > > > the result type and the first operand type must be compatible (signed > > > > and unsigned types are not compatible). In the above case, you have: > > > > integer_type_node = unsigned_int << integer_type_name . > > > > > > > > Does that make sense now? > > > > > > Btw, the error you see is still odd - please make sure to build GCC with > > > checking enabled or run your tests with -fchecking. For further help > > > > Sure. > > > > > it might be useful to post the patch you are testing to show where exactly > > > you are hooking into to add this statement. > > > > My goal is to transform below IR - > > > > _5 = (unsigned int) _4; > > D.2993 = __builtin_riscv_*
Re: Validation of adding left shift stmt at GIMPLE - [Custom GCC plugin]]
On Wed, Feb 23, 2022 at 12:52 PM Richard Biener wrote: > > On Tue, Feb 22, 2022 at 2:10 PM Shubham Narlawar > wrote: > > > > On Tue, Feb 22, 2022 at 3:55 PM Richard Biener > > wrote: > > > > > > On Tue, Feb 22, 2022 at 8:38 AM Shubham Narlawar > > > wrote: > > > > > > > > On Mon, Feb 21, 2022 at 1:02 PM Richard Biener > > > > wrote: > > > > > > > > > > On Sun, Feb 20, 2022 at 11:44 PM Andrew Pinski via Gcc > > > > > wrote: > > > > > > > > > > > > On Sun, Feb 20, 2022 at 10:45 AM Shubham Narlawar > > > > > > wrote: > > > > > > > > > > > > > > On Sat, Feb 19, 2022 at 1:15 AM Andrew Pinski > > > > > > > wrote: > > > > > > > > > > > > > > > > On Fri, Feb 18, 2022 at 11:04 AM Shubham Narlawar via Gcc > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > Hello, > > > > > > > > > > > > > > > > > > I want to know whether it is correct to add left shift > > > > > > > > > instruction to > > > > > > > > > a constant expression statement like "_3 + 4"? > > > > > > > > > > > > > > > > > > I am trying to add a left shift instruction in between below > > > > > > > > > GIMPLE > > > > > > > > > instructions - > > > > > > > > > > > > > > > > > >: > > > > > > > > > instrn_buffer.0_1 = instrn_buffer; > > > > > > > > > _2 = tree.cnt; > > > > > > > > > _3 = (int) _2; > > > > > > > > > _4 = _3 + 4; > > > > > > > > > _5 = (unsigned int) _4;// I want to add left shift > > > > > > > > > here > > > > > > > > > D.2993 = __builtin_riscv_sfploadi (instrn_buffer.0_1, 0, > > > > > > > > > _5); > > > > > > > > > //this is "stmt" > > > > > > > > > > > > > > > > > > I am using this snippet in custom gcc plugin - > > > > > > > > > > > > > > > > > > tree lshift_tmp = make_temp_ssa_name > > > > > > > > > (integer_type_node, > > > > > > > > > NULL, "slli"); > > > > > > > > > > > > > > > > A couple of things. > > > > > > > > I Noticed you use integer_type_node here. Why not the type of > > > > > > > > what is > > > > > > > > being replaced? > > > > > > > > That is the main thing I see right now. > > > > > > > > > > > > > > I want to apply left shift to a constant expression with 8 which > > > > > > > is an > > > > > > > integer. Since I am not replacing a statement, I am creating new > > > > > > > GIMPLE statement - > > > > > > > > > > > > > > tree shift_amt = build_int_cst (integer_type_node, 8); > > > > > > > > > > > > > > Here, I am not replacing any GIMPLE statement. Is this the > > > > > > > correct way > > > > > > > to do this? > > > > > > > > > > > > > > My goal is to left shift constant expression and update its usage > > > > > > > as below - > > > > > > > > > > > > > > _19 = (unsigned int) _18; > > > > > > > D.2996 = __builtin_riscv_sfploadi (lexer.5_16, 12, _19); > > > > > > > > > > > > > > into > > > > > > > > > > > > > > _19 = (unsigned int) _18; > > > > > > > temp = _19 << 8 > > > > > > > D.2996 = __builtin_riscv_sfploadi (lexer.5_16, 12, temp); > > > > > > > > > > > > > > I am storing the left shift result to the new ssa variable name > > > > > > > "temp" > > > > > > > and updating sfploadi parameters as expected. > > > > > > > > > > > > > > On
Ferching Rtl instruction corressponding to Gimple Call instruction
Hello, I want to collect complete rtl instruction corresponding to below gimple call - "__builtin_temp" I have gimple instructions of form - slli_31 = _2 << 8; srli_32 = slli_31 >> 8; add_33 = srli_32 + 15; _20 = __builtin_temp (instrn_buffer.36_1, 1, add_33); For that, I put breakpoint in expand_call() present in cfgexpand.c. I traced the execution from expand_call() and found out that the last filled rtl instruction is present at end of expand_assignment(). Is my understanding correct? I am getting rtl instructions of form - (reg:V64SF 100 [ _16 ]) or (reg:V64SF 69 L3 [orig:100 _16 ] [100]) >From above rtl insn dumps, it is clear that it does not represent complete information of gimple call - _20 = __builtin_temp (instrn_buffer.36_1, 1, add_33); Where can I get complete RTL instruction such that I would be able to extract operands like fld[4], fld[5]? Thanks and Regards, Shubham
Hoisting built-in call out of loop - LIM pass [tree-ssa-loop-im.c]
Hello,
[1] I want to achieve hosting of a custom built-in call out of loop that
loads an immediate value.
for (int i = 0; i < 4000; i++) {
_9 = (unsigned int) _1;
slli_6 = _9 << 8;
srli_36 = slli_6 >> 8;
li_37 = __builtin_load_immediate (15);//I want to hoist this
out of loop which will cause hoisting of add_39 stmt also
add_39 = srli_36 + li_37;
_10 = __builtin_foo (add_39, 1, _9);
}
First 5 instructions in the above loop are being inserted by a custom
gimple plugin whenever it sees a __builtin_foo().
LICM pass () could hoist below instructions out of loop -
_9 = (unsigned int) _1;
slli_6 = _9 << 8;
srli_36 = slli_6 >> 8;
I want to hoist below gimple statement out of loop
li_22 = __builtin_riscv_load_immediate(15); //BUILTIN_MD
I am generating above builtin call using a custom GCC gimple plugin using -
tree li_tmp_name = make_temp_ssa_name (integer_type_node,
NULL, "li");
tree load = build_int_cst (unsigned_type_node, 15);
gcall *li_stmt = gimple_build_call (decl,
1); //where decl is function_decl
gimple_call_set_lhs (li_stmt, li_tmp_name);
gimple_call_set_arg (li_stmt, 0, load);
gsi_insert_after (&gsi, li_stmt, GSI_NEW_STMT);
How do I make a GIMPLE function call as const such that loop invariant code
motion hoist it out of the loop.
[2] I tried below approaches to make it happen -
a. I made load_immediate decl as constant but that did not help
TREE_CONSTANT(decl) = 1
b. I teached licm pass to forcefull move out __builtin_load_immediate() by
introducing various checks but in the end, it alters function cfg and some
other pass like ""tree-ssa-loop-manip.c"" crashes here -
/* We should have met DEF_BB along the way. */
gcc_assert (pred != ENTRY_BLOCK_PTR_FOR_FN (cfun));
>From above approaches, making changes in licm pass is proving to be costly
and inappropriate. Is there any other way I can achieve it? I am guessing
making it a constant gimple function call with no side effects will be
hoisted automatically by LICM.
If yes, how can I make a gimple call as constant so that it is hoisted out
by LICM. Also, please suggest any other approaches to achieve it.
Thanks and Regards,
Shubham
