Re: Assigning the result of a function call to a variable in the Gfortran frontend

[Leslie Zhai]

在 2017年09月05日 14:14, Tobias Grosser 写道:

Hi Leslie,

I copied you in this thread as you currently worked quite a bit with
dragonegg and we are currently trying to generate metadata that makes it
easier to reason about multi-dimensional fortran arrays.

Best,
Tobias

On Mon, Sep 4, 2017, at 23:06, (IIIT) Siddharth Bhat wrote:

Hello,

I've been hacking on the Gfortran frontend to change array index
expressions to function calls, so that I can inspect them later on in the
pipeline. I go from Fortran -> LLVM IR (through dragonegg) where I will
look at the function call nodes.

However, I'm not able to generate correct IR for this. I can create
function call, but I am unable to assign the return value of a function
call to a variable here.

Here's a link to my experiments here: It includes a patch, a test file
and
the GIMPLE output



I rebase the patch for GCC v8.x at first:


diff --git a/gcc/fortran/trans-array.c b/gcc/fortran/trans-array.c
index 9efb531..73dad6e 100644
--- a/gcc/fortran/trans-array.c
+++ b/gcc/fortran/trans-array.c
@@ -3251,6 +3251,7 @@ gfc_conv_scalarized_array_ref (gfc_se * se, 
gfc_array_ref * ar)

   if (build_class_array_ref (se, tmp, index))
 return;

+  call_polly_index(&se->pre, index, ar);
   se->expr = gfc_build_array_ref (tmp, index, decl);
 }

@@ -3335,6 +3336,24 @@ build_array_ref (tree desc, tree offset, tree 
decl, tree vptr)

   return tmp;
 }

+// See: gfc_call_malloc
+static tree call_polly_index(stmtblock_t *parent_block, tree 
*original_index,

+gfc_array_ref *ar) {
+  tree fncall, var, result;
+  stmtblock_t block;
+
+  var = gfc_create_var(gfc_array_index_type, "pollyindex");
+  gfc_init_block (&block);
+
+  fncall = build_call_expr_loc(input_location, 
gfor_fndecl_polly_array_index, 0);

+  gfc_add_modify(&block, var, fold_convert(gfc_array_index_type, fncall));
+  result = gfc_finish_block (&block);
+  gfc_add_expr_to_block(parent_block, result);
+  return var;
+
+  // return var;
+}
+

 /* Build an array reference.  se->expr already holds the array descriptor.
This should be either a variable, indirect variable reference or 
component

diff --git a/gcc/fortran/trans-decl.c b/gcc/fortran/trans-decl.c
index 74d8606..28ddcfd 100644
--- a/gcc/fortran/trans-decl.c
+++ b/gcc/fortran/trans-decl.c
@@ -95,6 +95,7 @@ static int seen_ieee_symbol;

 /* Function declarations for builtin library functions.  */

+tree gfor_fndecl_polly_array_index;
 tree gfor_fndecl_pause_numeric;
 tree gfor_fndecl_pause_string;
 tree gfor_fndecl_stop_numeric;
@@ -3495,6 +3496,14 @@ gfc_build_builtin_function_decls (void)
   /* ERROR STOP doesn't return.  */
   TREE_THIS_VOLATILE (gfor_fndecl_error_stop_string) = 1;

+
+  printf("building polly_array_index function decl...\n");
+  gfor_fndecl_polly_array_index = gfc_build_library_function_decl (
+get_identifier (PREFIX("polly_array_index")),
+gfc_array_index_type, 0);
+  TREE_THIS_VOLATILE (gfor_fndecl_polly_array_index) = 1;
+  printf("built polly_array_index function decl...\n");
+
   gfor_fndecl_pause_numeric = gfc_build_library_function_decl (
 get_identifier (PREFIX("pause_numeric")),
 void_type_node, 1, gfc_int4_type_node);
diff --git a/gcc/fortran/trans.h b/gcc/fortran/trans.h
index d02f347..c8d24ec 100644
--- a/gcc/fortran/trans.h
+++ b/gcc/fortran/trans.h
@@ -781,6 +781,7 @@ struct gimplify_omp_ctx;
 void gfc_omp_firstprivatize_type_sizes (struct gimplify_omp_ctx *, tree);

 /* Runtime library function decls.  */
+extern GTY(()) tree gfor_fndecl_polly_array_index;
 extern GTY(()) tree gfor_fndecl_pause_numeric;
 extern GTY(()) tree gfor_fndecl_pause_string;
 extern GTY(()) tree gfor_fndecl_stop_numeric;


then I will rebuild GCC for investigation.



.

Help would be very much appreciated!

Thanks,
Siddharth.
--
Sending this from my phone, please excuse any typos!


--
Regards,
Leslie Zhai - https://reviews.llvm.org/p/xiangzhai/

[RFC] type promotion pass

[Prathamesh Kulkarni]

Hi,
I have attached revamped version of Kugan's original patch for type promotion
(https://gcc.gnu.org/ml/gcc-patches/2014-09/msg00472.html)
rebased on r249469. The motivation of the pass is to minimize
generation of subregs
to avoid redundant zero/sign extensions by carrying out computations
in PROMOTE_MODE
as much as possible on tree-level.

* Working of pass
The pass is dominator-based, and tries to promote type of def to
PROMOTE_MODE in each gimple stmt. Before beginning domwalk, all the
default definitions are promoted to PROMOTE_MODE
in promote_all_ssa_defined_with_nop (). The patch adds a new tree code
SEXT_EXPR to represent sign-extension on tree level. CONVERT_EXPR is
either replaced by an explicit sign or zero extension depending on the
signedness of operands.

The core of the pass is in following two routines:
a) promote_ssa: This pass looks at the def of gimple_stmt, and
promotes type of def to promoted_type in-place if possible. If it
cannot promote def in-place, then
it transforms:
def = def_stmt
to
new_def = def_stmt
def = convert_expr new_def
where new_def is a clone of def, and type of def is set to promoted_type.

b) fixup_use: The main intent is to "fix" uses of a promoted variable
to preserve semantics
of the code, for instance if the variable is used in stmt where it's
original type is required.
Another case is when def is not promoted by promote_ssa, but some uses
could be promoted.

promote_all_stmts () is the driver function that calls fixup_use and
promote_ssa for each stmt
within the basic block. The pass relies extensively on dom and vrp to
remove redundancies generated by the pass and is thus enabled only if
vrp is enabled.

Issues:
1] Pass ordering: type-promote pass generates too many redundancies
which can hamper other optimizations. One case I observed was on arm
when it inhibited path splitting optimization because the number of
stmts in basic block exceeded the value of
param-max-jump-thread-duplication-stmts. So I placed the pass just
before dom. I am not sure if this is a good approach. Maybe the pass
itself
should avoid generating redundant statements and not rely too much on
dom and vrp ?

2] Redundant copies left after the pass: When it's safe, vrp optimzies
_1 = op1 sext op2
into
_1 = op1

which leaves redundant copies that are not optimized away at GIMPLE level.
I placed pass_copy_prop after vrp to eliminate these copies but not sure if that
is ideal. Maybe we should do this during vrp itself as this is the
only case that
generates redundant copies ?

3] Backward phi's: Since we traverse in dominated order, fixup_use()
gets called first on a ssa_name that is an argument of a backward-phi.
If it promotes the type and later if promote_ssa() decides that the
ssa_name should not be promoted, then we have to again walk the
backward phi's to undo the "incorrect" promotion, which is done by
emitting a convert_expr back to the original type from promoted_type.
While I suppose it shouldn't affect correctness, it generates
redundant casts and was wondering if there's a better approach to
handle this issue.

* SPEC2k6 benchmarking:

Results of  benchmarking the patch for aarch64-linux-gnu cortex-a57:

Improved:
401.bzip2  +2.11%
459.GemsFDTD  +1.42%
464.h264ref   +1.96%
471.omnetpp  +1.05%
481.wrf+0.99%

Regressed:
447.dealII-1.34%
450.soplex  -1.54%
456.hmmer  -3.79%
482.sphinx3 -2.95%

The remaining benchmarks didn't have much difference. However there
was some noise
in the above run, and I suppose the numbers are not precise.
I will give another run with benchmarking. There was no significant
difference in code-size with and without patch for SPEC2k6.

* Validation

The patch passes bootstrap+test on x86_64-unknown-linux-gnu,
arm-linux-gnueabihf,
aarch64-linux-gnu and ppc64le-linux-gnu. On arm-linux-gnueabihf, and
aarch64-linux-gnu, there is following fallout:

1] gcc.dg/attr-alloc_size-11.c missing range info for signed char
(test for warnings, line 50)
The issue seems to be that we call reset_flow_sensitive_info(def) if
def is promoted and that invalidates value range which is probably
causing the regression.

2] gcc.dg/fold-narrowbopcst-1.c scan-tree-dump optimized " = _.* + 156"
This requires adjusting the scan-dump.

On ppc64le-linux-gnu, I am observing several regressions in the
testsuite. Most of these seem to be because type-promotion is
interfering with other optimizations, especially widening_mul and
bswap pass. Also observed fallout for some cases due to interference
with strlen, tail-call and jump-threading passes. I suppose I am not
seeing these on arm/aarch64 because ppc64 defines
PROMOTE_MODE to be DImode and aarch64 defines it to be SImode ? I am
working to fix performance regressions. However I would be grateful to
receive feedback on the pass, if it's going in the right direction.

Thanks,
Prathamesh
diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index 67d69c1c0d2..61e6df9acb2 100644
-

Issues when emitting sjlj dispatch table

[Claudiu Zissulescu]

Hi guys,

I found an ICE when emitting sjlj dispatch table for ARC. Namely, in 
sjlj_emit_dispatch_table() function, we create a dispatch table where the case 
elements are having the high value is set to NULL (except.c:1326). Later, these 
case statements are used by expand_sjlj_dispatch_table() (stmt.c:1006) where we 
create a case list requiring also the high element (stmt.c:1066). This leads to 
an error when we try to compute the high bounds in emit_case_dispatch_table() 
(stmt.c:786), due to the fact that high value is null.

In gcc7.x, we were initializing the high value of case elements in 
sjlj_emit_dispatch_table() with the CASE_LOW. Shouldn't we do the same thing, 
or do I miss something.

A test is attached, the error is visible for ARC backend, the option for the 
compiler should be -O2.

Thanks,
Claudiu


complex_io.ii
Description: complex_io.ii

Re: Issues when emitting sjlj dispatch table

[Richard Biener]

On Tue, Sep 5, 2017 at 12:20 PM, Claudiu Zissulescu
 wrote:
> Hi guys,
>
> I found an ICE when emitting sjlj dispatch table for ARC. Namely, in 
> sjlj_emit_dispatch_table() function, we create a dispatch table where the 
> case elements are having the high value is set to NULL (except.c:1326). 
> Later, these case statements are used by expand_sjlj_dispatch_table() 
> (stmt.c:1006) where we create a case list requiring also the high element 
> (stmt.c:1066). This leads to an error when we try to compute the high bounds 
> in emit_case_dispatch_table() (stmt.c:786), due to the fact that high value 
> is null.
>
> In gcc7.x, we were initializing the high value of case elements in 
> sjlj_emit_dispatch_table() with the CASE_LOW. Shouldn't we do the same thing, 
> or do I miss something.

A NULL CASE_HIGH means the case covers a single value, CASE_LOW.

Probably broken by Martins reorg.

Richard.

> A test is attached, the error is visible for ARC backend, the option for the 
> compiler should be -O2.
>
> Thanks,
> Claudiu

Re: Can we replace uses of vec with vec in the backwards threader?

[Aldy Hernandez]

On Wed, Aug 30, 2017 at 10:32 AM, Jeff Law  wrote:
> On 08/30/2017 04:41 AM, Aldy Hernandez wrote:

> If you're looking for further cleanups, pulling the rest of the FSM bits
> out of tree-ssa-threadupdate.c is ripe.  In particular this loop:
>
>  /* Jump-thread all FSM threads before other jump-threads.  */
>   for (i = 0; i < paths.length ();)
> [ ... ]
>
> If that was to get pulled out and moved into tree-ssa-threadbackwards.c,
> then you can probably skip the step that converts the vector of blocks
> into a vector of jump_thread_edge which then gets turned into an array
> of blocks.  In theory you just turn the vector of blocks into an array
> of blocks to match the api for duplicate_thread_path.

Hmm, it seems that the above loop you mention in
thread_through_all_blocks() still needs to iterate over a global
vec vector ("paths").  So we still need to go
through a vector of jump edges.

Aldy

Re: GNU Tools Cauldron 2017: OMP (Offloading and Multi Processing) BoF

[Thomas Schwinge]

Hi!

On Mon, 4 Sep 2017 22:59:36 +0200, Jan Hubicka  wrote:
> > As Honza told me recently, it has been proposed by Martin -- I don't know
> > which one ;-) -- and certainly makes sense, to have another OMP
> > (Offloading and Multi Processing) BoF at the GNU Tools Cauldron 2017,
> > which is currently scheduled for Saturday, 11:00 to 11:45.  That is, a
> > general OMP BoF session in addition to more specific individual
> > presentations.
> > 
> > Honza volunteered me to host it ;-) -- to which I'm not immediately
> 
> To be precise, I also volunteered Martin (Jambor) to propose it.
> In any case it seems it would be useful thing to have on programme. Let me
> know if I should keep it there ;)

Yes, let's keep it there, and I'm sure we'll find enough topics to
discuss with the group of people that are present (which I don't know
yet).

> > objecting, but my time to prepare anything at all is very limited
> > (non-existing?) right now, and I still got to first organize stuff/myself
> > for my other presentation slot...
> > 
> > We could do it off the cuff, but it'd also be very useful to know
> > beforehand a handful of topics to talk about.  So, who's interested in
> > contributing to this OMP BoF?  I put some candidates in CC, but
> > everyone's welcome to contribute, of course!  I suggest this should
> > really be BoF-like: more interaction and discussion instead of too much
> > presentation.

Here is an abstract/agenda for this time slot.  Are you going to put it
onto the wiki page, or want me to do it?

This is an interactive BoF to discuss all things OMP (Offloading and
Multi Processing): from front ends (programming abstractions: OpenMP,
OpenACC, maybe CPLEX (C Parallel Language Extensions)?, others?) to
support for heterogeneous offload targets/GCC back ends (Intel MIC,
Nvidia PTX, HSA/HSAIL, GCN, others?) -- and everything in between:
middle end abstractions.  Automatic vectorization, parallelization
(parloops/autopar, graphite, polly, others?).  Compilation flow in
GCC (LTO model, HSAIL model).  Issues with complex GCC build
configuration, problems for packagers, GNU/Linux distributions.


Grüße
 Thomas

Re: Can we replace uses of vec with vec in the backwards threader?

[Jeff Law]

On 09/05/2017 06:32 AM, Aldy Hernandez wrote:
> On Wed, Aug 30, 2017 at 10:32 AM, Jeff Law  wrote:
>> On 08/30/2017 04:41 AM, Aldy Hernandez wrote:
> 
>> If you're looking for further cleanups, pulling the rest of the FSM bits
>> out of tree-ssa-threadupdate.c is ripe.  In particular this loop:
>>
>>  /* Jump-thread all FSM threads before other jump-threads.  */
>>   for (i = 0; i < paths.length ();)
>> [ ... ]
>>
>> If that was to get pulled out and moved into tree-ssa-threadbackwards.c,
>> then you can probably skip the step that converts the vector of blocks
>> into a vector of jump_thread_edge which then gets turned into an array
>> of blocks.  In theory you just turn the vector of blocks into an array
>> of blocks to match the api for duplicate_thread_path.
> 
> Hmm, it seems that the above loop you mention in
> thread_through_all_blocks() still needs to iterate over a global
> vec vector ("paths").  So we still need to go
> through a vector of jump edges.
It's just finding the backwards paths that we converted into the
jump_thread_edge form.  Then we iterate over the edges in the path to
build an array of blocks.

So instead of converting our vec of blocks into a jump_thread_edge, we
just keep the vec of blocks when we pull that loop out of
tree-ssa-threadupdate.c.


That would also mean the immediately following loop should be dead.

Unless I'm missing something?!?

jeff

gcc-5-20170905 is now available

[gccadmin]

Snapshot gcc-5-20170905 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/5-20170905/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-5-branch 
revision 251746

You'll find:

 gcc-5-20170905.tar.xzComplete GCC

  SHA256=ae7aa2d791329599bdebaf6f3a1aa4ec56194e8b0a6f5bcb5bca2154a6a17bec
  SHA1=86f8350d9cffee0faf02c3aa263c27c7596f5a50

Diffs from 5-20170829 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-5
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Re: Assigning the result of a function call to a variable in the Gfortran frontend

[Leslie Zhai]

f (tree desc, tree offset, tree 
decl, tree vptr)

   return tmp;
 }

+// See: gfc_call_malloc
+static tree call_polly_index(stmtblock_t *parent_block, tree 
*original_index,

+gfc_array_ref *ar) {
+  tree fncall, var, result;
+  stmtblock_t block;
+
+  var = gfc_create_var(gfc_array_index_type, "pollyindex");
+  gfc_init_block (&block);
+
+  fncall = build_call_expr_loc(input_location, 
gfor_fndecl_polly_array_index, 0);
+  gfc_add_modify(&block, var, fold_convert(gfc_array_index_type, 
fncall));

+  result = gfc_finish_block (&block);
+  gfc_add_expr_to_block(parent_block, result);
+  return var;
+
+  // return var;
+}
+

 /* Build an array reference.  se->expr already holds the array 
descriptor.
This should be either a variable, indirect variable reference or 
component

diff --git a/gcc/fortran/trans-decl.c b/gcc/fortran/trans-decl.c
index 74d8606..28ddcfd 100644
--- a/gcc/fortran/trans-decl.c
+++ b/gcc/fortran/trans-decl.c
@@ -95,6 +95,7 @@ static int seen_ieee_symbol;

 /* Function declarations for builtin library functions.  */

+tree gfor_fndecl_polly_array_index;
 tree gfor_fndecl_pause_numeric;
 tree gfor_fndecl_pause_string;
 tree gfor_fndecl_stop_numeric;
@@ -3495,6 +3496,14 @@ gfc_build_builtin_function_decls (void)
   /* ERROR STOP doesn't return.  */
   TREE_THIS_VOLATILE (gfor_fndecl_error_stop_string) = 1;

+
+  printf("building polly_array_index function decl...\n");
+  gfor_fndecl_polly_array_index = gfc_build_library_function_decl (
+get_identifier (PREFIX("polly_array_index")),
+gfc_array_index_type, 0);
+  TREE_THIS_VOLATILE (gfor_fndecl_polly_array_index) = 1;
+  printf("built polly_array_index function decl...\n");
+
   gfor_fndecl_pause_numeric = gfc_build_library_function_decl (
 get_identifier (PREFIX("pause_numeric")),
 void_type_node, 1, gfc_int4_type_node);
diff --git a/gcc/fortran/trans.h b/gcc/fortran/trans.h
index d02f347..c8d24ec 100644
--- a/gcc/fortran/trans.h
+++ b/gcc/fortran/trans.h
@@ -781,6 +781,7 @@ struct gimplify_omp_ctx;
 void gfc_omp_firstprivatize_type_sizes (struct gimplify_omp_ctx *, 
tree);


 /* Runtime library function decls.  */
+extern GTY(()) tree gfor_fndecl_polly_array_index;
 extern GTY(()) tree gfor_fndecl_pause_numeric;
 extern GTY(()) tree gfor_fndecl_pause_string;
 extern GTY(()) tree gfor_fndecl_stop_numeric;


then I will rebuild GCC for investigation.


$ /opt/gcc-git/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/opt/gcc-git/bin/gcc
COLLECT_LTO_WRAPPER=/opt/gcc-git/libexec/gcc/x86_64-redhat-linux-gnu/8.0.0/lto-wrapper
Target: x86_64-redhat-linux-gnu
Configured with: ../configure --target=x86_64-redhat-linux-gnu 
--host=x86_64-redhat-linux-gnu --build=x86_64-redhat-linux-gnu 
--with-cpu=generic --prefix=/opt/gcc-git --enable-bootstrap 
--enable-shared --enable-threads=posix --enable-checking=release 
--enable-languages=c,c++,lto,go,fortran,objc,obj-c++ --enable-plugin 
--enable-initfini-array --enable-gnu-unique-object 
--enable-linker-build-id --with-linker-hash-style=gnu 
--enable-__cxa_atexit --enable-gnu-indirect-function --enable-c99 
--enable-long-long --enable-libgomp --enable-lto --enable-libsanitizer 
--enable-libatomic --enable-libquadmath --enable-libitm 
--enable-libcilkrts --enable-libmpx --enable-symvers 
--disable-libstdcxx-pch --disable-multilib --disable-libunwind-exceptions

Thread model: posix
gcc version 8.0.0 20170905 (experimental) (GCC)


$ /opt/gcc-git/bin/gcc -o m.o -c -g -Wall -Wextra -fPIC -fdump-tree-all  
m.f90

building polly_array_index function decl...
built polly_array_index function decl...
m.f90:12:17:

 coeff
 1
Warning: Unused variable ‘coeff’ declared at (1) [-Wunused-variable]


call_polly_index not be called? please rebase the patch for GCC v8.0, 
thanks!






.

Help would be very much appreciated!

Thanks,
Siddharth.
--
Sending this from my phone, please excuse any typos!




--
Regards,
Leslie Zhai - https://reviews.llvm.org/p/xiangzhai/

Re: Assigning the result of a function call to a variable in the Gfortran frontend

[Tobias Grosser]

 (PREFIX("pause_numeric")),
>   void_type_node, 1, gfc_int4_type_node);
> diff --git a/gcc/fortran/trans.h b/gcc/fortran/trans.h
> index d02f347..c8d24ec 100644
> --- a/gcc/fortran/trans.h
> +++ b/gcc/fortran/trans.h
> @@ -781,6 +781,7 @@ struct gimplify_omp_ctx;
>   void gfc_omp_firstprivatize_type_sizes (struct gimplify_omp_ctx *,
>   tree);
> 
>   /* Runtime library function decls.  */
> +extern GTY(()) tree gfor_fndecl_polly_array_index;
>   extern GTY(()) tree gfor_fndecl_pause_numeric;
>   extern GTY(()) tree gfor_fndecl_pause_string;
>   extern GTY(()) tree gfor_fndecl_stop_numeric;
> 
> 
> 
> >
> >
> >
> > diff --git a/gcc/fortran/trans-array.c b/gcc/fortran/trans-array.c
> > index 9efb531..73dad6e 100644
> > --- a/gcc/fortran/trans-array.c
> > +++ b/gcc/fortran/trans-array.c
> > @@ -3251,6 +3251,7 @@ gfc_conv_scalarized_array_ref (gfc_se * se, 
> > gfc_array_ref * ar)
> >if (build_class_array_ref (se, tmp, index))
> >  return;
> >
> > +  call_polly_index(&se->pre, index, ar);
> >se->expr = gfc_build_array_ref (tmp, index, decl);
> >  }
> >
> > @@ -3335,6 +3336,24 @@ build_array_ref (tree desc, tree offset, tree 
> > decl, tree vptr)
> >return tmp;
> >  }
> >
> > +// See: gfc_call_malloc
> > +static tree call_polly_index(stmtblock_t *parent_block, tree 
> > *original_index,
> > +gfc_array_ref *ar) {
> > +  tree fncall, var, result;
> > +  stmtblock_t block;
> > +
> > +  var = gfc_create_var(gfc_array_index_type, "pollyindex");
> > +  gfc_init_block (&block);
> > +
> > +  fncall = build_call_expr_loc(input_location, 
> > gfor_fndecl_polly_array_index, 0);
> > +  gfc_add_modify(&block, var, fold_convert(gfc_array_index_type, 
> > fncall));
> > +  result = gfc_finish_block (&block);
> > +  gfc_add_expr_to_block(parent_block, result);
> > +  return var;
> > +
> > +  // return var;
> > +}
> > +
> >
> >  /* Build an array reference.  se->expr already holds the array 
> > descriptor.
> > This should be either a variable, indirect variable reference or 
> > component
> > diff --git a/gcc/fortran/trans-decl.c b/gcc/fortran/trans-decl.c
> > index 74d8606..28ddcfd 100644
> > --- a/gcc/fortran/trans-decl.c
> > +++ b/gcc/fortran/trans-decl.c
> > @@ -95,6 +95,7 @@ static int seen_ieee_symbol;
> >
> >  /* Function declarations for builtin library functions.  */
> >
> > +tree gfor_fndecl_polly_array_index;
> >  tree gfor_fndecl_pause_numeric;
> >  tree gfor_fndecl_pause_string;
> >  tree gfor_fndecl_stop_numeric;
> > @@ -3495,6 +3496,14 @@ gfc_build_builtin_function_decls (void)
> >/* ERROR STOP doesn't return.  */
> >TREE_THIS_VOLATILE (gfor_fndecl_error_stop_string) = 1;
> >
> > +
> > +  printf("building polly_array_index function decl...\n");
> > +  gfor_fndecl_polly_array_index = gfc_build_library_function_decl (
> > +get_identifier (PREFIX("polly_array_index")),
> > +gfc_array_index_type, 0);
> > +  TREE_THIS_VOLATILE (gfor_fndecl_polly_array_index) = 1;
> > +  printf("built polly_array_index function decl...\n");
> > +
> >gfor_fndecl_pause_numeric = gfc_build_library_function_decl (
> >  get_identifier (PREFIX("pause_numeric")),
> >  void_type_node, 1, gfc_int4_type_node);
> > diff --git a/gcc/fortran/trans.h b/gcc/fortran/trans.h
> > index d02f347..c8d24ec 100644
> > --- a/gcc/fortran/trans.h
> > +++ b/gcc/fortran/trans.h
> > @@ -781,6 +781,7 @@ struct gimplify_omp_ctx;
> >  void gfc_omp_firstprivatize_type_sizes (struct gimplify_omp_ctx *, 
> > tree);
> >
> >  /* Runtime library function decls.  */
> > +extern GTY(()) tree gfor_fndecl_polly_array_index;
> >  extern GTY(()) tree gfor_fndecl_pause_numeric;
> >  extern GTY(()) tree gfor_fndecl_pause_string;
> >  extern GTY(()) tree gfor_fndecl_stop_numeric;
> >
> >
> > then I will rebuild GCC for investigation.
> 
> $ /opt/gcc-git/bin/gcc -v
> Using built-in specs.
> COLLECT_GCC=/opt/gcc-git/bin/gcc
> COLLECT_LTO_WRAPPER=/opt/gcc-git/libexec/gcc/x86_64-redhat-linux-gnu/8.0.0/lto-wrapper
> Target: x86_64-redhat-linux-gnu
> Configured with: ../configure --target=x86_64-redhat-linux-gnu 
> --host=x86_64-redhat-linux-gnu --build=x86_64-redhat-linux-gnu 
> --with-cpu=generic --prefix=/opt/gcc-git --enable-bootstrap 
> --enable-shared --enable-threads=posix --enable-checking=release 
> --enable-languages=c,c++,lto,go,fortran,objc,obj-c++ --enable-plugin 
> --enable-initfini-array --enable-gnu-unique-object 
> --enable-linker-build-id --with-linker-hash-style=gnu 
> --enable-__cxa_atexit --enable-gnu-indirect-function --enable-c99 
> --enable-long-long --enable-libgomp --enable-lto --enable-libsanitizer 
> --enable-libatomic --enable-libquadmath --enable-libitm 
> --enable-libcilkrts --enable-libmpx --enable-symvers 
> --disable-libstdcxx-pch --disable-multilib --disable-libunwind-exceptions
> Thread model: posix
> gcc version 8.0.0 20170905 (experimental) (GCC)
> 
> 
> $ /opt/gcc-git/bin/gcc -o m.o -c -g -Wall -Wextra -fPIC -fdump-tree-all  
> m.f90
> building polly_array_index function decl...
> built polly_array_index function decl...
> m.f90:12:17:
> 
>   coeff
>   1
> Warning: Unused variable ‘coeff’ declared at (1) [-Wunused-variable]
> 
> 
> call_polly_index not be called? please rebase the patch for GCC v8.0, 
> thanks!
> 
> >
> >
> >>> .
> >>>
> >>> Help would be very much appreciated!
> >>>
> >>> Thanks,
> >>> Siddharth.
> >>> -- 
> >>> Sending this from my phone, please excuse any typos!
> >
> 
> -- 
> Regards,
> Leslie Zhai - https://reviews.llvm.org/p/xiangzhai/
> 
> 
> 

Re: Assigning the result of a function call to a variable in the Gfortran frontend

[Leslie Zhai]

rray_ref (se, tmp, index))
  return;

+  call_polly_index(&se->pre, index, ar);
se->expr = gfc_build_array_ref (tmp, index, decl);
  }

@@ -3335,6 +3336,24 @@ build_array_ref (tree desc, tree offset, tree
decl, tree vptr)
return tmp;
  }

+// See: gfc_call_malloc
+static tree call_polly_index(stmtblock_t *parent_block, tree
*original_index,
+gfc_array_ref *ar) {
+  tree fncall, var, result;
+  stmtblock_t block;
+
+  var = gfc_create_var(gfc_array_index_type, "pollyindex");
+  gfc_init_block (&block);
+
+  fncall = build_call_expr_loc(input_location,
gfor_fndecl_polly_array_index, 0);
+  gfc_add_modify(&block, var, fold_convert(gfc_array_index_type,
fncall));
+  result = gfc_finish_block (&block);
+  gfc_add_expr_to_block(parent_block, result);
+  return var;
+
+  // return var;
+}
+

  /* Build an array reference.  se->expr already holds the array
descriptor.
 This should be either a variable, indirect variable reference or
component
diff --git a/gcc/fortran/trans-decl.c b/gcc/fortran/trans-decl.c
index 74d8606..28ddcfd 100644
--- a/gcc/fortran/trans-decl.c
+++ b/gcc/fortran/trans-decl.c
@@ -95,6 +95,7 @@ static int seen_ieee_symbol;

  /* Function declarations for builtin library functions.  */

+tree gfor_fndecl_polly_array_index;
  tree gfor_fndecl_pause_numeric;
  tree gfor_fndecl_pause_string;
  tree gfor_fndecl_stop_numeric;
@@ -3495,6 +3496,14 @@ gfc_build_builtin_function_decls (void)
/* ERROR STOP doesn't return.  */
TREE_THIS_VOLATILE (gfor_fndecl_error_stop_string) = 1;

+
+  printf("building polly_array_index function decl...\n");
+  gfor_fndecl_polly_array_index = gfc_build_library_function_decl (
+get_identifier (PREFIX("polly_array_index")),
+gfc_array_index_type, 0);
+  TREE_THIS_VOLATILE (gfor_fndecl_polly_array_index) = 1;
+  printf("built polly_array_index function decl...\n");
+
gfor_fndecl_pause_numeric = gfc_build_library_function_decl (
  get_identifier (PREFIX("pause_numeric")),
  void_type_node, 1, gfc_int4_type_node);
diff --git a/gcc/fortran/trans.h b/gcc/fortran/trans.h
index d02f347..c8d24ec 100644
--- a/gcc/fortran/trans.h
+++ b/gcc/fortran/trans.h
@@ -781,6 +781,7 @@ struct gimplify_omp_ctx;
  void gfc_omp_firstprivatize_type_sizes (struct gimplify_omp_ctx *,
tree);

  /* Runtime library function decls.  */
+extern GTY(()) tree gfor_fndecl_polly_array_index;
  extern GTY(()) tree gfor_fndecl_pause_numeric;
  extern GTY(()) tree gfor_fndecl_pause_string;
  extern GTY(()) tree gfor_fndecl_stop_numeric;


then I will rebuild GCC for investigation.

$ /opt/gcc-git/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/opt/gcc-git/bin/gcc
COLLECT_LTO_WRAPPER=/opt/gcc-git/libexec/gcc/x86_64-redhat-linux-gnu/8.0.0/lto-wrapper
Target: x86_64-redhat-linux-gnu
Configured with: ../configure --target=x86_64-redhat-linux-gnu
--host=x86_64-redhat-linux-gnu --build=x86_64-redhat-linux-gnu
--with-cpu=generic --prefix=/opt/gcc-git --enable-bootstrap
--enable-shared --enable-threads=posix --enable-checking=release
--enable-languages=c,c++,lto,go,fortran,objc,obj-c++ --enable-plugin
--enable-initfini-array --enable-gnu-unique-object
--enable-linker-build-id --with-linker-hash-style=gnu
--enable-__cxa_atexit --enable-gnu-indirect-function --enable-c99
--enable-long-long --enable-libgomp --enable-lto --enable-libsanitizer
--enable-libatomic --enable-libquadmath --enable-libitm
--enable-libcilkrts --enable-libmpx --enable-symvers
--disable-libstdcxx-pch --disable-multilib --disable-libunwind-exceptions
Thread model: posix
gcc version 8.0.0 20170905 (experimental) (GCC)


$ /opt/gcc-git/bin/gcc -o m.o -c -g -Wall -Wextra -fPIC -fdump-tree-all
m.f90
building polly_array_index function decl...
built polly_array_index function decl...
m.f90:12:17:

   coeff
   1
Warning: Unused variable ‘coeff’ declared at (1) [-Wunused-variable]


call_polly_index not be called? please rebase the patch for GCC v8.0,
thanks!


but the patch for GCC v8.0 is not able to work? call_polly_index *not* 
be called?







.

Help would be very much appreciated!

Thanks,
Siddharth.
--
Sending this from my phone, please excuse any typos!

--
Regards,
Leslie Zhai - https://reviews.llvm.org/p/xiangzhai/





--
Regards,
Leslie Zhai - https://reviews.llvm.org/p/xiangzhai/