Question about comparing function function decls

[Gary Oblock via Gcc]

I'm trying to determine during LTO optimization (with one partition)
whether of not a function call is to a function in the partition.

Here is the routine I've written. Note, I'm willing to admit up front
that the comparison below ( ) is probably dicey.

---
static bool
is_user_function ( gimple *call_stmt)
{
  tree fndecl = gimple_call_fndecl ( call_stmt);

  DEBUG_L("is_user_function: decl in: %p,", fndecl);
  DEBUG_F( print_generic_decl, stderr, fndecl, (dump_flags_t)-1);
  DEBUG("\n");
  INDENT(2);

  cgraph_node* node;
  bool ret_val = false;
  FOR_EACH_FUNCTION_WITH_GIMPLE_BODY ( node)
  {
DEBUG_L("decl %p,", node->decl);
DEBUG_F( print_generic_decl, stderr, node->decl, (dump_flags_t)-1);
DEBUG("\n");

if ( node->decl == fndecl )
  {
ret_val = true;
break;
  }
  }

  INDENT(-2);
  return ret_val;
}
---

Here's the test program I was compiling.

-- aux.h --
#include "stdlib.h"
typedef struct type type_t;
struct type {
  int i;
  double x;
};

#define MAX(x,y) ((x)>(y) ? (x) : (y))

extern int max1( type_t *, size_t);
extern double max2( type_t *, size_t);
extern type_t *setup( size_t);
-- aux.c --
#include "aux.h"
#include "stdlib.h"

type_t *
setup( size_t size)
{
  type_t *data = (type_t *)malloc( size * sizeof(type_t));
  size_t i;
  for( i = 0; i < size; i++ ) {
data[i].i = rand();
data[i].x = drand48();
  }
  return data;
}

int
max1( type_t *array, size_t len)
{
  size_t i;
  int result = array[0].i;
  for( i = 1; i < len; i++  ) {
result = MAX( array[i].i, result);
  }
  return result;
}

double
max2( type_t *array, size_t len)
{
  size_t i;
  double result = array[0].x;
  for( i = 1; i < len; i++  ) {
result = MAX( array[i].x, result);
  }
  return result;
}
-- main.c -
#include "aux.h"
#include "stdio.h"

type_t *data1;

int
main(void)
{
  type_t *data2 = setup(200);
  data1 = setup(100);

  printf("First %d\n" , max1(data1,100));
  printf("Second %e\n", max2(data2,200));
}
---

The output follows:

---
L# 1211: is_user_function: decl in: 0x7f078461be00,  static intD. 
max1D. (struct type_t *, size_t);
L# 1222:   decl 0x7f078462,  static struct type_t * setupD. (size_t);
L# 1222:   decl 0x7f078461bf00,  static intD. max1.constprop.0D. 
(struct type_t *);
L# 1222:   decl 0x7f078461bd00,  static doubleD. max2.constprop.0D. 
(struct type_t *);
L# 1222:   decl 0x7f078461bb00,  static intD. mainD. (void);
---

Now it's pretty obvious that constant propagation decided the size_t
len arguments to max1 and max2 were no longer needed. However, the
function declaration information on the calls to them weren't updated
so they'll never match. Now if there is another way to see if the
function is in the partition or if there is some other way to compare
the functions in a partition, please let me know.

Thanks,

Gary Oblock
Ampere Computing

PS. The body of the message is attached in a file because my email program
(Outlook) mangled the above.



CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for 
the sole use of the intended recipient(s) and contains information that is 
confidential and proprietary to Ampere Computing or its subsidiaries. It is to 
be used solely for the purpose of furthering the parties' business 
relationship. Any review, copying, or distribution of this email (or any 
attachments thereto) is strictly prohibited. If you are not the intended 
recipient, please contact the sender immediately and permanently delete the 
original and any copies of this email and any attachments thereto.


gcc_msg
Description: gcc_msg

GIMPLE problem

[Gary Oblock via Gcc]

I'm somehow misusing GIMPLE (probably in multiple ways) and I need
some help in straightening out this little mess I've made.

I'm trying to do the following:

In an attempt at structure reorganization (instance interleaving) an
array of structures is being transformed into a structure of arrays.

for the simple example I'm using
typedef struct type type_t;
struct type {
  double x;
  double y;
};
.
.
type_t *data = (type_t *)malloc( len * sizeof(type_t));
.
.
result = data[i].y;

Is transformed into this or something close to it

typedef long _reorg_SP_ptr_type_type_t
typedef struct _reorg_base_type_type_t _reorg_base_type_type_t

struct _reorg_base_type_type_t {
 double *x;
 double *y;
};

_reorg_SP_ptr_type_type_t data;

_reorg_base_type_type_t _reorg_base_var_type_t;

// Note I'm ignoring a bunch of stuff that needs to happen
// when a malloc fails..
_reorg_base_var_type_t.x = (double*)malloc( len*sizeof(double));
_reorg_base_var_type_t.y = (double*)malloc( len*sizeof(double));

data = 0;
.
.
double *temp = _reorg_base_var_type_t.y;
result = temp[i];

Now, believe it or not the the whole bit above, except for "result = data[i].y",
seems to work just fine.

I attempted to do this (result = data[i].y) via basically two different
ways. One is using ARRAY_REF and in the other faking an array access with
INDIRECT_REF. The first approach chokes on the fact that temp is a pointer
and the second dies in ssa operand scanning because it doesn't have a case
for INDIRECT_REF.

The code below shows both ways. What have I done wrong here and what to
I need to do differently to get it to work?

Thanks,

Gary

PS Please ignore the then case below.


 gimple_stmt_iterator gsi = gsi_for_stmt( stmt);

 // Dump for debugging
 print_gimple_stmt ( stderr, stmt, 0);

 tree lhs = gimple_assign_lhs( stmt);
 tree rhs = gimple_assign_rhs1( stmt);

 bool ro_on_left = tree_contains_a_reorgtype_p ( lhs, info);

 tree ro_side = ro_on_left ? lhs : rhs;
 tree nonro_side = ro_on_left ? rhs : lhs;

 switch ( recognize_op ( ro_side, info) )  // "a->f"
   {
   case ReorgOpT_Indirect:
 {
   tree orig_field = TREE_OPERAND( ro_side, 1);
   tree field_type = TREE_TYPE( orig_field);
   tree base = ri->instance_interleave.base;

   tree base_field =
   find_coresponding_field ( base, orig_field);

   tree base_field_type = TREE_TYPE( base_field);

   tree field_val_temp =
 make_temp_ssa_name( field_type, NULL, "field_val_temp");

   tree inner_op = TREE_OPERAND( ro_side, 0);

   // For either case generate common code:

   // field_array = _base.f
   tree field_arry_addr =
   make_temp_ssa_name( base_field_type, NULL, "field_arry_addr");

   tree rhs_faa = build3 ( COMPONENT_REF,
  //base_field_type, // This doesn't work
  ptr_type_node, // This seems bogus
  base,
 //base_field, // This doesn't work
 orig_field, // This seems bogus
 NULL_TREE);

   // Use this to access the array of element.
   gimple *get_field_arry_addr =
   gimple_build_assign( field_arry_addr, rhs_faa);

  // index = a
  tree index =
make_temp_ssa_name( ri->pointer_rep, NULL, "index");
  gimple *get_index =
gimple_build_assign( index, inner_op);

  gimple *temp_set;
  gimple *final_set;

  #if WITH_INDIRECT
  // offset = index * size_of_field
  tree size_of_field = TYPE_SIZE_UNIT ( base_field_type);
  tree offset = make_temp_ssa_name( sizetype, NULL, "offset");

  gimple *get_offset =
gimple_build_assign ( offset, MULT_EXPR, index, size_of_field);

  // field_addr = field_array + offset
  // bug fix here (TBD) type must be *double not double
  tree field_addr =
make_temp_ssa_name( base_field_type, NULL, "field_addr");

  gimple *get_field_addr =
gimple_build_assign ( field_addr, PLUS_EXPR, field_arry_addr, 
offset);
  #endif

  if ( ro_on_left )
{
   // With:a->f = rhs
   // Generate:

   //   temp = rhs
   temp_set = gimple_build_assign( field_val_temp, rhs);

   #if WITH_INDIRECT
   // NOTE, THIS (MEM_REF) SHOULD NOT WORK (IGNORE THIS PLEASE!)
   // not tested yet! I know THIS bit won't work.
   // *field_addr = temp
   tree lhs_ref = build1 ( MEM_REF, field_type, field_addr);
   #else
   // field_arry_addr[index]
   tree lhs_ref =
 bu

Re: GIMPLE problem

[Gary Oblock via Gcc]

Richard,

First off I did suspect INDIRECT_REF wasn't supported, thanks for
confirming that.

I tried what you said in the original code before I posted
but I suspect how I went at it is the problem. I'm probably
doing something(s) in a glaringly stupid way.

Can you spot it, because everything I'm doing makes total sense
to me?

Thanks Gary

--

Snippet from the code with MEM_REF:

  tree lhs_ref = build1 ( MEM_REF, field_type, field_addr);

  final_set = gimple_build_assign( lhs_ref, field_val_temp);

field_type is a double *

field_addr is an address within an malloced array of doubles.

--

Snippet from the code with ARRAY_REF:

  tree rhs_ref = build4 ( ARRAY_REF, field_type, field_arry_addr, index,
  NULL_TREE, NULL_TREE);

  temp_set = gimple_build_assign( field_val_temp, rhs_ref);

field type is double

field_arry_addr is the starting address of an array of malloced doubles.

index is a pointer_rep (an integer)
  details:
tree pointer_rep = make_node ( INTEGER_TYPE);
TYPE_PRECISION (pointer_rep) = TYPE_PRECISION (pointer_sized_int_node);

An problematic interaction between a call created by gimple_build_call and inlining

[Gary Oblock via Gcc]

I'm trying to generate calls to "free" on the fly at ipa time.

I've tried several things (given below) but they both fail
in expand_call_inline in tree-inline.c on this gcc_checking_assert:

  cg_edge = id->dst_node->get_edge (stmt);
  gcc_checking_assert (cg_edge);

Now, I've tried using the built in free via:

  tree fndecl_free = builtin_decl_explicit( BUILT_IN_FREE);
  // Note to_free is set between here and the call by an assign
  tree to_free =
make_temp_ssa_name( reorg_pointer_type, NULL, "malloc_to_free");
  .
  .
  gcall *free_call = gimple_build_call( fndecl_free, 1, to_free);

or building the fndecl from scrath:

  tree fntype = build_function_type ( free_return_type, param_type_list);
  tree fnname = get_identifier ( "free");
  tree fndecl_free =
build_decl ( input_location, FUNCTION_DECL, fnname, fntype);
  gcall *free_call = gimple_build_call( fndecl_free, 1, to_free);

Note, I was able to get something similar to work for "malloc" by
using the fndecl I extracted from an existing malloc call.

Your advice on how to build a fndecl that doesn't have this
problem is appreciated.

Thanks,

Gary Oblock


CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for 
the sole use of the intended recipient(s) and contains information that is 
confidential and proprietary to Ampere Computing or its subsidiaries. It is to 
be used solely for the purpose of furthering the parties' business 
relationship. Any review, copying, or distribution of this email (or any 
attachments thereto) is strictly prohibited. If you are not the intended 
recipient, please contact the sender immediately and permanently delete the 
original and any copies of this email and any attachments thereto.

Re: An problematic interaction between a call created by gimple_build_call and inlining

[Gary Oblock via Gcc]

Thank you Richard.

I feel a bit dumb because I'm well aware of the GCC philosophy to have
any new code produced update the state.  Of course I didn't know the
commands to do this for the call graph (which I really appreciate you giving.)

However, the real reason I'm sending a reply is this. Are there any surprising
cases in IPA where GCC violates its philosophy and actually regenerates the
information?

Thanks again,

Gary


From: Richard Biener 
Sent: Wednesday, July 1, 2020 12:27 AM
To: Gary Oblock 
Cc: gcc@gcc.gnu.org 
Subject: Re: An problematic interaction between a call created by 
gimple_build_call and inlining

[EXTERNAL EMAIL NOTICE: This email originated from an external sender. Please 
be mindful of safe email handling and proprietary information protection 
practices.]


On Wed, Jul 1, 2020 at 7:49 AM Gary Oblock via Gcc  wrote:
>
> I'm trying to generate calls to "free" on the fly at ipa time.
>
> I've tried several things (given below) but they both fail
> in expand_call_inline in tree-inline.c on this gcc_checking_assert:
>
>   cg_edge = id->dst_node->get_edge (stmt);
>   gcc_checking_assert (cg_edge);

It simply means you are operating at a point where we expect
callgraph edges to be present but you fail to update the callgraph
for your added function call.  it might be as easy as calling

cgraph_node::get (cfun->decl)->create_edge (cgraph_node::get_create
(fndecl_free), free_call, gimple_bb (free_call)->count);

> Now, I've tried using the built in free via:
>
>   tree fndecl_free = builtin_decl_explicit( BUILT_IN_FREE);
>   // Note to_free is set between here and the call by an assign
>   tree to_free =
> make_temp_ssa_name( reorg_pointer_type, NULL, "malloc_to_free");
>   .
>   .
>   gcall *free_call = gimple_build_call( fndecl_free, 1, to_free);
>
> or building the fndecl from scrath:
>
>   tree fntype = build_function_type ( free_return_type, param_type_list);
>   tree fnname = get_identifier ( "free");
>   tree fndecl_free =
> build_decl ( input_location, FUNCTION_DECL, fnname, fntype);
>   gcall *free_call = gimple_build_call( fndecl_free, 1, to_free);
>
> Note, I was able to get something similar to work for "malloc" by
> using the fndecl I extracted from an existing malloc call.
>
> Your advice on how to build a fndecl that doesn't have this
> problem is appreciated.
>
> Thanks,
>
> Gary Oblock
>
>
> CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is 
> for the sole use of the intended recipient(s) and contains information that 
> is confidential and proprietary to Ampere Computing or its subsidiaries. It 
> is to be used solely for the purpose of furthering the parties' business 
> relationship. Any review, copying, or distribution of this email (or any 
> attachments thereto) is strictly prohibited. If you are not the intended 
> recipient, please contact the sender immediately and permanently delete the 
> original and any copies of this email and any attachments thereto.

Re: An problematic interaction between a call created by gimple_build_call and inlining

[Gary Oblock via Gcc]

Martin,

What about immediate dominators?

Thanks,

Gary


From: Martin Jambor 
Sent: Wednesday, July 1, 2020 3:40 PM
To: Gary Oblock ; Richard Biener 

Cc: gcc@gcc.gnu.org 
Subject: Re: An problematic interaction between a call created by 
gimple_build_call and inlining

[EXTERNAL EMAIL NOTICE: This email originated from an external sender. Please 
be mindful of safe email handling and proprietary information protection 
practices.]


Hi,

On Wed, Jul 01 2020, Gary Oblock via Gcc wrote:
> Thank you Richard.
>
> I feel a bit dumb because I'm well aware of the GCC philosophy to have
> any new code produced update the state.  Of course I didn't know the
> commands to do this for the call graph (which I really appreciate you giving.)
>
> However, the real reason I'm sending a reply is this. Are there any surprising
> cases in IPA where GCC violates its philosophy and actually regenerates the
> information?

if by "the information" you specifically mean call graph edges then no.
(Regular) IPA optimizations are designed to also work when doing link
time optimization (LTO) which means that unless they specifically load
the (gimple) bodies of some selected functions, the bodies are not
available to them.  They only operate on the call graph and information
they collected when generating summaries.  Because gimple body is not
available, call graph edges cannot be regenerated from it.

In fact, when a call is redirected to a different/specialized function,
at IPA time it is only recored in the call graph by redirecting the
corresponding edge and the call statement is modified only at the end of
IPA phase (in LTRANS in LTO-speak).  This is necessary even when not
using LTO because until specialized nodes get their own body, they share
it with the node from which they were cloned.  That means that several
call graph edges, which do not share caller and may not even share the
callee, refer to the same gimple statement - so the decl in the
statement is actually meaningless and the edge encodes the important
information.

Martin

Questions regarding control flow during IPA passes

[Gary Oblock via Gcc]

At IPA time I'm creating GIMPLE statements. I've noticed during dumps
that gotos and labels don't seem to exist. In fact when I tried
introducing them, at least the gotos, failed.  I assume that at this
point in compilation GCC relies on the control flow graph (which I'm
updating as I create new BBs) so I actually shouldn't create them?
Furthermore, I assume I should be setting the "gotos" in the condition
statement to NULL?

Thanks,

Gary Oblock
Ampere Computing
Santa Clara, California


CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for 
the sole use of the intended recipient(s) and contains information that is 
confidential and proprietary to Ampere Computing or its subsidiaries. It is to 
be used solely for the purpose of furthering the parties' business 
relationship. Any review, copying, or distribution of this email (or any 
attachments thereto) is strictly prohibited. If you are not the intended 
recipient, please contact the sender immediately and permanently delete the 
original and any copies of this email and any attachments thereto.

Re: An problematic interaction between a call created by gimple_build_call and inlining

[Gary Oblock via Gcc]

Martin,

Actually it's basic blocks that dominate on another though I suppose you could 
generalize the notion to CFG edges but to what point?

I'm seeing in some of the code that I read, immediate dominators being manually 
computed and added to the BBs at their point of creation. At the moment I'm 
punting on creating them hoping I don't create an untenable state which results 
in hard to diagnose failures. I was just trying to avoid this.

Thanks,

Gary Oblock


From: Martin Jambor 
Sent: Friday, July 3, 2020 1:59 AM
To: Gary Oblock ; Richard Biener 

Cc: gcc@gcc.gnu.org 
Subject: Re: An problematic interaction between a call created by 
gimple_build_call and inlining

Hi,

On Thu, Jul 02 2020, Gary Oblock wrote:
> Martin,
>
> What about immediate dominators?

I'm afraid I don't understand your question, what about them?

Dominators are re-computed after inlining and after clones are
materialized (when they get their own body)... I believe.

We do not store information which call graph edges dominate other call
graph edges in the callers body.  Having that information might be
useful at IPA stage.

But yeah, please be more specific what your question is.

Martin

>
> 
> From: Martin Jambor 
> Sent: Wednesday, July 1, 2020 3:40 PM
> To: Gary Oblock ; Richard Biener 
> 
> Cc: gcc@gcc.gnu.org 
> Subject: Re: An problematic interaction between a call created by 
> gimple_build_call and inlining
>
> [EXTERNAL EMAIL NOTICE: This email originated from an external sender. Please 
> be mindful of safe email handling and proprietary information protection 
> practices.]
>
>
> Hi,
>
> On Wed, Jul 01 2020, Gary Oblock via Gcc wrote:
>> Thank you Richard.
>>
>> I feel a bit dumb because I'm well aware of the GCC philosophy to have
>> any new code produced update the state.  Of course I didn't know the
>> commands to do this for the call graph (which I really appreciate you 
>> giving.)
>>
>> However, the real reason I'm sending a reply is this. Are there any 
>> surprising
>> cases in IPA where GCC violates its philosophy and actually regenerates the
>> information?
>
> if by "the information" you specifically mean call graph edges then no.
> (Regular) IPA optimizations are designed to also work when doing link
> time optimization (LTO) which means that unless they specifically load
> the (gimple) bodies of some selected functions, the bodies are not
> available to them.  They only operate on the call graph and information
> they collected when generating summaries.  Because gimple body is not
> available, call graph edges cannot be regenerated from it.
>
> In fact, when a call is redirected to a different/specialized function,
> at IPA time it is only recored in the call graph by redirecting the
> corresponding edge and the call statement is modified only at the end of
> IPA phase (in LTRANS in LTO-speak).  This is necessary even when not
> using LTO because until specialized nodes get their own body, they share
> it with the node from which they were cloned.  That means that several
> call graph edges, which do not share caller and may not even share the
> callee, refer to the same gimple statement - so the decl in the
> statement is actually meaningless and the edge encodes the important
> information.
>
> Martin

Help on a bug showing up in a template

[Gary Oblock via Gcc]

I'm encountering a really painful error. The stack trace is below.

The code in hash-table.h is a template and it is really hyper-allergic
to instrumentation (a couple of fprintfs caused malloc to have an
internal error!)  Last time I checked gbd didn't exactly play nice
with templates either. Note, I tried adding --enable-checking=all to
my configure but all that did was cause a library installation failure.

If anybody has any clues about how to handle this kind of a bug or
even better yet if you have an a idea of what I did wrong then please
let me know.

Note, the particular optimization I'm working on is done at IPA time
and involve creating a bunce of gimple stmts, new types, new ssa temps
and changing the types of some existing declarations and ssa temps.

Thanks,

Gary

-


during IPA pass: inline
dump file: ./exe.ltrans0.ltrans.079i.inline
main.c: In function ‘main’:
main.c:18:11: internal compiler error: Segmentation fault
   18 |   max_y = max_of_y( data, len);
  |   ^
0xcbb4af crash_signal
../../source/gcc/toplev.c:328
0xd24d66 hash_table::find_with_hash(tree_node* const&, unsigned int)
../../source/gcc/hash-table.h:925
0xd21d23 ssa_default_def(function*, tree_node*)
../../source/gcc/tree-dfa.c:315
0xd56988 setup_one_parameter
../../source/gcc/tree-inline.c:3429
0xd5cb35 initialize_inlined_parameters
../../source/gcc/tree-inline.c:3585
0xd5cb35 expand_call_inline
../../source/gcc/tree-inline.c:4936
0xd5f8e9 gimple_expand_calls_inline
../../source/gcc/tree-inline.c:5266
0xd5f8e9 optimize_inline_calls(tree_node*)
../../source/gcc/tree-inline.c:5439
0xa02023 inline_transform(cgraph_node*)
../../source/gcc/ipa-inline-transform.c:736
0xb8d979 execute_one_ipa_transform_pass
../../source/gcc/passes.c:2233
0xb8d979 execute_all_ipa_transforms(bool)
../../source/gcc/passes.c:2272
0x75c15b cgraph_node::expand()
../../source/gcc/cgraphunit.c:2294
0x75d858 expand_all_functions
../../source/gcc/cgraphunit.c:2472
0x75d858 symbol_table::compile()
../../source/gcc/cgraphunit.c:2823
0x6963d1 lto_main()
../../source/gcc/lto/lto.c:653
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
lto-wrapper: fatal error: /home/gary/gcc_expt_build/install/bin/gcc returned 1 
exit status
compilation terminated.
/usr/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status
./script: line 10: ./exe: No such file or directory



CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for 
the sole use of the intended recipient(s) and contains information that is 
confidential and proprietary to Ampere Computing or its subsidiaries. It is to 
be used solely for the purpose of furthering the parties' business 
relationship. Any review, copying, or distribution of this email (or any 
attachments thereto) is strictly prohibited. If you are not the intended 
recipient, please contact the sender immediately and permanently delete the 
original and any copies of this email and any attachments thereto.

Default defs question

[Gary Oblock via Gcc]

Regarding the other question I asked today could somebody explain to
me what the default_defs are all about. I suspect I'm doing something
wrong with regard of them. Note, I've isolated the failure in the last email
down to this bit (in red):

if (is_empty (*entry)
  || (!is_deleted (*entry) && Descriptor::equal (*entry, comparable))

Which doesn't make much sense to me.

Thanks,

Gary


CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for 
the sole use of the intended recipient(s) and contains information that is 
confidential and proprietary to Ampere Computing or its subsidiaries. It is to 
be used solely for the purpose of furthering the parties' business 
relationship. Any review, copying, or distribution of this email (or any 
attachments thereto) is strictly prohibited. If you are not the intended 
recipient, please contact the sender immediately and permanently delete the 
original and any copies of this email and any attachments thereto.

Three issues

[Gary Oblock via Gcc]

Some background:

This is in the dreaded structure reorganization optimization that I'm
working on. It's running at LTRANS time with '-flto-partition=one'.

My issues in order of importance are:

1) In gimple-ssa.h, the equal method for ssa_name_hasher
has a segfault because the "var" field of "a" is (nil).

struct ssa_name_hasher : ggc_ptr_hash
{
  /* Hash a tree in a uid_decl_map.  */

  static hashval_t
  hash (tree item)
  {
return item->ssa_name.var->decl_minimal.uid;
  }

  /* Return true if the DECL_UID in both trees are equal.  */

  static bool
  equal (tree a, tree b)
  {
  return (a->ssa_name.var->decl_minimal.uid == 
b->ssa_name.var->decl_minimal.uid);
  }
};

The parameter "a" is associated with "*entry" on the 2nd to last
line shown (it's trimmed off after that.) This from hash-table.h:

template class Allocator>
typename hash_table::value_type &
hash_table
::find_with_hash (const compare_type &comparable, hashval_t hash)
{
  m_searches++;
  size_t size = m_size;
  hashval_t index = hash_table_mod1 (hash, m_size_prime_index);

  if (Lazy && m_entries == NULL)
m_entries = alloc_entries (size);

#if CHECKING_P
  if (m_sanitize_eq_and_hash)
verify (comparable, hash);
#endif

  value_type *entry = &m_entries[index];
  if (is_empty (*entry)
  || (!is_deleted (*entry) && Descriptor::equal (*entry, comparable)))
return *entry;
  .
  .

Is there any way this could happen other than by a memory corruption
of some kind? This is a show stopper for me and I really need some help on
this issue.

2) I tried to dump out all the gimple in the following way at the very
beginning of my program:

void
print_program ( FILE *file, int leading_space )
{
  struct cgraph_node *node;
  fprintf ( file, "%*sProgram:\n", leading_space, "");

  // Print Global Decls
  //
  varpool_node *var;
  FOR_EACH_VARIABLE ( var)
  {
tree decl = var->decl;
fprintf ( file, "%*s", leading_space, "");
print_generic_decl ( file, decl, (dump_flags_t)0);
fprintf ( file, "\n");
  }

  FOR_EACH_FUNCTION_WITH_GIMPLE_BODY ( node)
  {
struct function *func = DECL_STRUCT_FUNCTION ( node->decl);
dump_function_header ( file, func->decl, (dump_flags_t)0);
dump_function_to_file ( func->decl, file, (dump_flags_t)0);
  }
}

When I run this the first two (out of three) functions print
just fine. However, for the third, func->decl is (nil) and
it segfaults.

Now the really odd thing is that this works perfectly at the
end or middle of my optimization.

What gives?

3) For my bug in (1) I got so distraught that I ran valgrind which
in my experience is an act of desperation for compilers.

None of the errors it spotted are associated with my optimization
(although it oh so cleverly pointed out the segfault) however it
showed the following:

==18572== Invalid read of size 8
==18572==at 0x1079DC1: execute_one_pass(opt_pass*) (passes.c:2550)
==18572==by 0x107ABD3: execute_ipa_pass_list(opt_pass*) (passes.c:2929)
==18572==by 0xAC0E52: symbol_table::compile() (cgraphunit.c:2786)
==18572==by 0x9915A9: lto_main() (lto.c:653)
==18572==by 0x11EE4A0: compile_file() (toplev.c:458)
==18572==by 0x11F1888: do_compile() (toplev.c:2302)
==18572==by 0x11F1BA3: toplev::main(int, char**) (toplev.c:2441)
==18572==by 0x23C021E: main (main.c:39)
==18572==  Address 0x5842880 is 16 bytes before a block of size 88 alloc'd
==18572==at 0x4C3017F: operator new(unsigned long) (in 
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==18572==by 0x21E00B7: make_pass_ipa_prototype(gcc::context*) 
(ipa-prototype.c:329)
==18572==by 0x106E987: gcc::pass_manager::pass_manager(gcc::context*) 
(pass-instances.def:178)
==18572==by 0x11EFCE8: general_init(char const*, bool) (toplev.c:1250)
==18572==by 0x11F1A86: toplev::main(int, char**) (toplev.c:2391)
==18572==by 0x23C021E: main (main.c:39)
==18572==

Are these known issues with lto or is this a valgrind issue?

Thanks,

Gary


CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for 
the sole use of the intended recipient(s) and contains information that is 
confidential and proprietary to Ampere Computing or its subsidiaries. It is to 
be used solely for the purpose of furthering the parties' business 
relationship. Any review, copying, or distribution of this email (or any 
attachments thereto) is strictly prohibited. If you are not the intended 
recipient, please contact the sender immediately and permanently delete the 
original and any copies of this email and any attachments thereto.

Re: Three issues

[Gary Oblock via Gcc]

David,

Note, for the first explanation, this is the hash table for the default defs 
and not
some private pass specific table so I'm not directly touching it in way. 
However, that
doesn't mean some other common or not so common function I'm invoking has
the side effect of doing this in some pathological way (you point this out by 
asking
if they are my temporaries.) I do create temporaries but I certainly make no 
attempt
to add them to the default defs. In fact, I went so far as to instrument the 
code that
adds them to see if I was doing this but I found nothing. This likely means I'm 
causing
a subtle memory corruption or something I'm doing has bad side effects.

The second option (not an explanation) has me diddling some fairly important 
stuff
that I don't know all that much about therefore I prefer to find and fix the 
root cause.

Thanks,

Gary




From: David Malcolm 
Sent: Wednesday, July 22, 2020 12:31 AM
To: Gary Oblock ; gcc@gcc.gnu.org 
Subject: Re: Three issues

[EXTERNAL EMAIL NOTICE: This email originated from an external sender. Please 
be mindful of safe email handling and proprietary information protection 
practices.]


On Tue, 2020-07-21 at 22:49 +, Gary Oblock via Gcc wrote:
> Some background:
>
> This is in the dreaded structure reorganization optimization that I'm
> working on. It's running at LTRANS time with '-flto-partition=one'.
>
> My issues in order of importance are:
>
> 1) In gimple-ssa.h, the equal method for ssa_name_hasher
> has a segfault because the "var" field of "a" is (nil).
>
> struct ssa_name_hasher : ggc_ptr_hash
> {
>   /* Hash a tree in a uid_decl_map.  */
>
>   static hashval_t
>   hash (tree item)
>   {
> return item->ssa_name.var->decl_minimal.uid;
>   }
>
>   /* Return true if the DECL_UID in both trees are equal.  */
>
>   static bool
>   equal (tree a, tree b)
>   {
>   return (a->ssa_name.var->decl_minimal.uid == b->ssa_name.var-
> >decl_minimal.uid);
>   }
> };

I notice that tree.h has:

/* Returns the variable being referenced.  This can be NULL_TREE for
   temporaries not associated with any user variable.
   Once released, this is the only field that can be relied upon.  */
#define SSA_NAME_VAR(NODE)  \
  (SSA_NAME_CHECK (NODE)->ssa_name.var == NULL_TREE \
   || TREE_CODE ((NODE)->ssa_name.var) == IDENTIFIER_NODE   \
   ? NULL_TREE : (NODE)->ssa_name.var)

So presumably that ssa_name_hasher is making an implicit assumption
that such temporaries aren't present in the hash_table; maybe they are
for yours?

Is this a hash_table that you're populating yourself?

With the caveat that I'm sleep-deprived, another way this could happen
is if "a" is not an SSA_NAME but is in fact some other kind of tree;
you could try replacing
  a->ssa_name.ver
with
  SSA_NAME_CHECK (a)->ssa_name.var
(and similarly for b)

But the first explanation seems more likely.


>
[...snip qn 2...]


> 3) For my bug in (1) I got so distraught that I ran valgrind which
> in my experience is an act of desperation for compilers.
>
> None of the errors it spotted are associated with my optimization
> (although it oh so cleverly pointed out the segfault) however it
> showed the following:
>
> ==18572== Invalid read of size 8
> ==18572==at 0x1079DC1: execute_one_pass(opt_pass*)
> (passes.c:2550)

What is line 2550 of passes.c in your working copy?

==18572==by 0x107ABD3: execute_ipa_pass_list(opt_pass*)
> (passes.c:2929)
> ==18572==by 0xAC0E52: symbol_table::compile() (cgraphunit.c:2786)
> ==18572==by 0x9915A9: lto_main() (lto.c:653)
> ==18572==by 0x11EE4A0: compile_file() (toplev.c:458)
> ==18572==by 0x11F1888: do_compile() (toplev.c:2302)
> ==18572==by 0x11F1BA3: toplev::main(int, char**) (toplev.c:2441)
> ==18572==by 0x23C021E: main (main.c:39)
> ==18572==  Address 0x5842880 is 16 bytes before a block of size 88
> alloc'd
> ==18572==at 0x4C3017F: operator new(unsigned long) (in
> /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==18572==by 0x21E00B7: make_pass_ipa_prototype(gcc::context*)
> (ipa-prototype.c:329)

You say above that none of the errors are associated with your
optimization, but presumably this is your new pass, right?  Can you
post the code somewhere?

> ==18572==by 0x106E987:
> gcc::pass_manager::pass_manager(gcc::context*) (pass-
> instances.def:178)
> ==18572==by 0x11EFCE8: general_init(char const*, bool)
> (toplev.c:1250)
> ==18572==by 0x11F1A86: toplev::main(int, char**) (toplev.c:2391)
> ==18572==by 0x23C021E: main (main.c:39)
> ==18572==
>
> Are these known issues with lto or is this a valgrind issue?

Hope this is helpful
Dave

Re: Three issues

[Gary Oblock via Gcc]

Richard,

I was really hopeful about your suggestions but I went over my code and
anything that modified anything had a cfun_push and cfun_pop associated with it.

Also, enabling the extra annotations didn't make a difference.

I'm thinking a wolf fence test that scans for malformed default_def hash table
entries is my only recourse at this point.

Thanks,

Gary

From: Richard Biener 
Sent: Wednesday, July 22, 2020 2:32 AM
To: Gary Oblock 
Cc: gcc@gcc.gnu.org 
Subject: Re: Three issues

[EXTERNAL EMAIL NOTICE: This email originated from an external sender. Please 
be mindful of safe email handling and proprietary information protection 
practices.]


On Wed, Jul 22, 2020 at 12:51 AM Gary Oblock via Gcc  wrote:
>
> Some background:
>
> This is in the dreaded structure reorganization optimization that I'm
> working on. It's running at LTRANS time with '-flto-partition=one'.
>
> My issues in order of importance are:
>
> 1) In gimple-ssa.h, the equal method for ssa_name_hasher
> has a segfault because the "var" field of "a" is (nil).
>
> struct ssa_name_hasher : ggc_ptr_hash
> {
>   /* Hash a tree in a uid_decl_map.  */
>
>   static hashval_t
>   hash (tree item)
>   {
> return item->ssa_name.var->decl_minimal.uid;
>   }
>
>   /* Return true if the DECL_UID in both trees are equal.  */
>
>   static bool
>   equal (tree a, tree b)
>   {
>   return (a->ssa_name.var->decl_minimal.uid == 
> b->ssa_name.var->decl_minimal.uid);
>   }
> };
>
> The parameter "a" is associated with "*entry" on the 2nd to last
> line shown (it's trimmed off after that.) This from hash-table.h:
>
> template template class Allocator>
> typename hash_table::value_type &
> hash_table
> ::find_with_hash (const compare_type &comparable, hashval_t hash)
> {
>   m_searches++;
>   size_t size = m_size;
>   hashval_t index = hash_table_mod1 (hash, m_size_prime_index);
>
>   if (Lazy && m_entries == NULL)
> m_entries = alloc_entries (size);
>
> #if CHECKING_P
>   if (m_sanitize_eq_and_hash)
> verify (comparable, hash);
> #endif
>
>   value_type *entry = &m_entries[index];
>   if (is_empty (*entry)
>   || (!is_deleted (*entry) && Descriptor::equal (*entry, comparable)))
> return *entry;
>   .
>   .
>
> Is there any way this could happen other than by a memory corruption
> of some kind? This is a show stopper for me and I really need some help on
> this issue.
>
> 2) I tried to dump out all the gimple in the following way at the very
> beginning of my program:
>
> void
> print_program ( FILE *file, int leading_space )
> {
>   struct cgraph_node *node;
>   fprintf ( file, "%*sProgram:\n", leading_space, "");
>
>   // Print Global Decls
>   //
>   varpool_node *var;
>   FOR_EACH_VARIABLE ( var)
>   {
> tree decl = var->decl;
> fprintf ( file, "%*s", leading_space, "");
> print_generic_decl ( file, decl, (dump_flags_t)0);
> fprintf ( file, "\n");
>   }
>
>   FOR_EACH_FUNCTION_WITH_GIMPLE_BODY ( node)
>   {
> struct function *func = DECL_STRUCT_FUNCTION ( node->decl);
> dump_function_header ( file, func->decl, (dump_flags_t)0);
> dump_function_to_file ( func->decl, file, (dump_flags_t)0);
>   }
> }
>
> When I run this the first two (out of three) functions print
> just fine. However, for the third, func->decl is (nil) and
> it segfaults.
>
> Now the really odd thing is that this works perfectly at the
> end or middle of my optimization.
>
> What gives?
>
> 3) For my bug in (1) I got so distraught that I ran valgrind which
> in my experience is an act of desperation for compilers.
>
> None of the errors it spotted are associated with my optimization
> (although it oh so cleverly pointed out the segfault) however it
> showed the following:
>
> ==18572== Invalid read of size 8
> ==18572==at 0x1079DC1: execute_one_pass(opt_pass*) (passes.c:2550)
> ==18572==by 0x107ABD3: execute_ipa_pass_list(opt_pass*) (passes.c:2929)
> ==18572==by 0xAC0E52: symbol_table::compile() (cgraphunit.c:2786)
> ==18572==by 0x9915A9: lto_main() (lto.c:653)
> ==18572==by 0x11EE4A0: compile_file() (toplev.c:458)
> ==18572==by 0x11F1888: do_compile() (toplev.c:2302)
> ==18572==by 0x11F1BA3: toplev::main(int, char**) (toplev.c:2441)
> ==18572==by 0x23C021E: main (main.c:39)
> ==18572==  Address 0x5842880 is 16 bytes before a block of size 88 alloc'd
> ==18572==at 0x4C3017F: operator new(unsigned long) (in 
> /usr/lib/valgrind/vgpre

Re: Three issues

[Gary Oblock via Gcc]

Richard,

My wolf fence failed to detect an issue at the end of my pass
so I'm now hunting for a problem I caused in a following pass.

Your thoughts?

Gary

- Wolf Fence Follows -
int
wf_func ( tree *slot, tree *dummy)
{
  tree t_val = *slot;
  gcc_assert( t_val->ssa_name.var);
  return 0;
}

void
wolf_fence (
Info *info // Pass level gobal info (might not use it)
  )
{
  struct cgraph_node *node;
  fprintf( stderr,
  "Wolf Fence: Find wolf via gcc_assert(t_val->ssa_name.var)\n");
  FOR_EACH_FUNCTION_WITH_GIMPLE_BODY ( node)
{
  struct function *func = DECL_STRUCT_FUNCTION ( node->decl);
  push_cfun ( func);
  DEFAULT_DEFS ( func)->traverse_noresize < tree *, wf_func> ( NULL);
  pop_cfun ();
}
  fprintf( stderr, "Wolf Fence: Didn't find wolf!\n");
}

From: Richard Biener 
Sent: Wednesday, July 22, 2020 2:32 AM
To: Gary Oblock 
Cc: gcc@gcc.gnu.org 
Subject: Re: Three issues

[EXTERNAL EMAIL NOTICE: This email originated from an external sender. Please 
be mindful of safe email handling and proprietary information protection 
practices.]


On Wed, Jul 22, 2020 at 12:51 AM Gary Oblock via Gcc  wrote:
>
> Some background:
>
> This is in the dreaded structure reorganization optimization that I'm
> working on. It's running at LTRANS time with '-flto-partition=one'.
>
> My issues in order of importance are:
>
> 1) In gimple-ssa.h, the equal method for ssa_name_hasher
> has a segfault because the "var" field of "a" is (nil).
>
> struct ssa_name_hasher : ggc_ptr_hash
> {
>   /* Hash a tree in a uid_decl_map.  */
>
>   static hashval_t
>   hash (tree item)
>   {
> return item->ssa_name.var->decl_minimal.uid;
>   }
>
>   /* Return true if the DECL_UID in both trees are equal.  */
>
>   static bool
>   equal (tree a, tree b)
>   {
>   return (a->ssa_name.var->decl_minimal.uid == 
> b->ssa_name.var->decl_minimal.uid);
>   }
> };
>
> The parameter "a" is associated with "*entry" on the 2nd to last
> line shown (it's trimmed off after that.) This from hash-table.h:
>
> template template class Allocator>
> typename hash_table::value_type &
> hash_table
> ::find_with_hash (const compare_type &comparable, hashval_t hash)
> {
>   m_searches++;
>   size_t size = m_size;
>   hashval_t index = hash_table_mod1 (hash, m_size_prime_index);
>
>   if (Lazy && m_entries == NULL)
> m_entries = alloc_entries (size);
>
> #if CHECKING_P
>   if (m_sanitize_eq_and_hash)
> verify (comparable, hash);
> #endif
>
>   value_type *entry = &m_entries[index];
>   if (is_empty (*entry)
>   || (!is_deleted (*entry) && Descriptor::equal (*entry, comparable)))
> return *entry;
>   .
>   .
>
> Is there any way this could happen other than by a memory corruption
> of some kind? This is a show stopper for me and I really need some help on
> this issue.
>
> 2) I tried to dump out all the gimple in the following way at the very
> beginning of my program:
>
> void
> print_program ( FILE *file, int leading_space )
> {
>   struct cgraph_node *node;
>   fprintf ( file, "%*sProgram:\n", leading_space, "");
>
>   // Print Global Decls
>   //
>   varpool_node *var;
>   FOR_EACH_VARIABLE ( var)
>   {
> tree decl = var->decl;
> fprintf ( file, "%*s", leading_space, "");
> print_generic_decl ( file, decl, (dump_flags_t)0);
> fprintf ( file, "\n");
>   }
>
>   FOR_EACH_FUNCTION_WITH_GIMPLE_BODY ( node)
>   {
> struct function *func = DECL_STRUCT_FUNCTION ( node->decl);
> dump_function_header ( file, func->decl, (dump_flags_t)0);
> dump_function_to_file ( func->decl, file, (dump_flags_t)0);
>   }
> }
>
> When I run this the first two (out of three) functions print
> just fine. However, for the third, func->decl is (nil) and
> it segfaults.
>
> Now the really odd thing is that this works perfectly at the
> end or middle of my optimization.
>
> What gives?
>
> 3) For my bug in (1) I got so distraught that I ran valgrind which
> in my experience is an act of desperation for compilers.
>
> None of the errors it spotted are associated with my optimization
> (although it oh so cleverly pointed out the segfault) however it
> showed the following:
>
> ==18572== Invalid read of size 8
> ==18572==at 0x1079DC1: execute_one_pass(opt_pass*) (passes.c:2550)
> ==18572==by 0x107ABD3: execute_ipa_pass_list(opt_pass*) (passes.c:2929)
> ==18572==by 0xAC0E52: symbol_table::compile() (cgraphunit.c:2786)
> ==18

Problems with changing the type of an ssa name

[Gary Oblock via Gcc]

If you've followed what I've been up to via my questions
on the mailing list, I finally traced my latest big problem
back to to my own code. In a nut shell here is what
I'm doing.

I'm creating a new type exaactly like this:

tree pointer_rep =
  make_signed_type ( TYPE_PRECISION ( pointer_sized_int_node));
TYPE_MAIN_VARIANT ( pointer_rep) =
  TYPE_MAIN_VARIANT ( pointer_sized_int_node);
const char *gcc_name =
  identifier_to_locale ( IDENTIFIER_POINTER ( TYPE_NAME ( ri->gcc_type)));
size_t len =
  strlen ( REORG_SP_PTR_PREFIX) + strlen ( gcc_name);
char *name = ( char *)alloca(len + 1);
strcpy ( name, REORG_SP_PTR_PREFIX);
strcat ( name, gcc_name);
TYPE_NAME ( pointer_rep) = get_identifier ( name);

I detect an ssa_name that I want to change to have this type
and change it thusly. Note, this particular ssa_name is a
default def which I seems to be very pertinent (since it's
the only case that fails.)

modify_ssa_name_type ( an_ssa_name, pointer_rep);

void
modify_ssa_name_type ( tree ssa_name, tree type)
{
  // This rips off the code in make_ssa_name_fn with a
  // modification or two.

  if ( TYPE_P ( type) )
{
   TREE_TYPE ( ssa_name) = TYPE_MAIN_VARIANT ( type);
   if ( ssa_defined_default_def_p ( ssa_name) )
  {
 // I guessing which I know is a terrible thing to do...
 SET_SSA_NAME_VAR_OR_IDENTIFIER ( ssa_name, TYPE_MAIN_VARIANT ( 
type));
   }
 else
   {
 // The following breaks defaults defs hence the check above.
 SET_SSA_NAME_VAR_OR_IDENTIFIER ( ssa_name, NULL_TREE);
   }
}
 else
{
  TREE_TYPE ( ssa_name) = TREE_TYPE ( type);
  SET_SSA_NAME_VAR_OR_IDENTIFIER ( ssa_name, type);
}
}

After this it dies when trying to call print_generic_expr with the ssa name.

Here's the bottom most complaint from the internal error:

tree check: expected tree that contains ‘decl minimal’ structure, have 
‘integer_type’ in dump_generic_node, at tree-pretty-print.c:3154

Can anybody tell what I'm doing wrong?

Thank,

Gary




CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for 
the sole use of the intended recipient(s) and contains information that is 
confidential and proprietary to Ampere Computing or its subsidiaries. It is to 
be used solely for the purpose of furthering the parties' business 
relationship. Any review, copying, or distribution of this email (or any 
attachments thereto) is strictly prohibited. If you are not the intended 
recipient, please contact the sender immediately and permanently delete the 
original and any copies of this email and any attachments thereto.

Re: Problems with changing the type of an ssa name

[Gary Oblock via Gcc]

Richard,

I suppose that might be doable but aren't there any ramifications
from the fact that the problematic ssa_names are the default defs?
I can imagine easily replacing all the ssa names except those that
are default defs.

Gary

From: Richard Biener 
Sent: Friday, July 24, 2020 11:16 PM
To: Gary Oblock ; Gary Oblock via Gcc 
; gcc@gcc.gnu.org 
Subject: Re: Problems with changing the type of an ssa name

[EXTERNAL EMAIL NOTICE: This email originated from an external sender. Please 
be mindful of safe email handling and proprietary information protection 
practices.]


On July 25, 2020 7:30:48 AM GMT+02:00, Gary Oblock via Gcc  
wrote:
>If you've followed what I've been up to via my questions
>on the mailing list, I finally traced my latest big problem
>back to to my own code. In a nut shell here is what
>I'm doing.
>
>I'm creating a new type exaactly like this:
>
>tree pointer_rep =
>  make_signed_type ( TYPE_PRECISION ( pointer_sized_int_node));
>TYPE_MAIN_VARIANT ( pointer_rep) =
>  TYPE_MAIN_VARIANT ( pointer_sized_int_node);
>const char *gcc_name =
>identifier_to_locale ( IDENTIFIER_POINTER ( TYPE_NAME (
>ri->gcc_type)));
>size_t len =
>  strlen ( REORG_SP_PTR_PREFIX) + strlen ( gcc_name);
>char *name = ( char *)alloca(len + 1);
>strcpy ( name, REORG_SP_PTR_PREFIX);
>strcat ( name, gcc_name);
>TYPE_NAME ( pointer_rep) = get_identifier ( name);
>
>I detect an ssa_name that I want to change to have this type
>and change it thusly. Note, this particular ssa_name is a
>default def which I seems to be very pertinent (since it's
>the only case that fails.)
>
>modify_ssa_name_type ( an_ssa_name, pointer_rep);
>
>void
>modify_ssa_name_type ( tree ssa_name, tree type)
>{
>  // This rips off the code in make_ssa_name_fn with a
>  // modification or two.
>
>  if ( TYPE_P ( type) )
>{
>   TREE_TYPE ( ssa_name) = TYPE_MAIN_VARIANT ( type);
>   if ( ssa_defined_default_def_p ( ssa_name) )
>  {
> // I guessing which I know is a terrible thing to do...
> SET_SSA_NAME_VAR_OR_IDENTIFIER ( ssa_name, TYPE_MAIN_VARIANT ( type));
>   }
> else
>   {
>   // The following breaks defaults defs hence the check above.
> SET_SSA_NAME_VAR_OR_IDENTIFIER ( ssa_name, NULL_TREE);
>   }
>}
> else
>{
>  TREE_TYPE ( ssa_name) = TREE_TYPE ( type);
>  SET_SSA_NAME_VAR_OR_IDENTIFIER ( ssa_name, type);
>}
>}
>
>After this it dies when trying to call print_generic_expr with the ssa
>name.
>
>Here's the bottom most complaint from the internal error:
>
>tree check: expected tree that contains ‘decl minimal’ structure, have
>‘integer_type’ in dump_generic_node, at tree-pretty-print.c:3154
>
>Can anybody tell what I'm doing wrong?

Do not modify existing SSA names, instead create a new one and replace uses of 
the old.

Richard.

>Thank,
>
>Gary
>
>
>
>
>CONFIDENTIALITY NOTICE: This e-mail message, including any attachments,
>is for the sole use of the intended recipient(s) and contains
>information that is confidential and proprietary to Ampere Computing or
>its subsidiaries. It is to be used solely for the purpose of furthering
>the parties' business relationship. Any review, copying, or
>distribution of this email (or any attachments thereto) is strictly
>prohibited. If you are not the intended recipient, please contact the
>sender immediately and permanently delete the original and any copies
>of this email and any attachments thereto.

Re: Problems with changing the type of an ssa name

[Gary Oblock via Gcc]

Richard,

As you know I'm working on a structure reorganization optimization.
The particular one I'm working on is called instance interleaving.
For the particular case I'm working on now, there is a single array
of structures being transformed, a pointer to an element of the
array is transformed into an index into what is now a structure
of arrays. Note, I did share my HL design document with you so
there are more details in there if you need them. So what all this
means is for this example

typedef struct fu fu_t;
struct fu {
  char x;
  inty;
  double z;
};
  :
  :
  fu_t *fubar = (fu_t*)malloc(...);
  fu_t *baz;

That fubar and baz no longer are pointer types and need to be
transformed into some integer type (say _index_fu_t.) Thus if
I encounter an ssa_name of type "fu_t *", I'll need to modify its
type be _index_fu_t. This is of course equivalent to replacing
that ssa name with a new one of type _index_fu_t.

Now, how do I actually do either of these? My attempts at
former all failed and the  later seems equally difficult for
the default defs. Note, prefer modifying them to replacing
them because it seems more reasonable and it also seems
to work except for the default defs.

I really need some help with this Richard.

Thanks,

Gary

From: Richard Biener 
Sent: Saturday, July 25, 2020 10:48 PM
To: Gary Oblock ; gcc@gcc.gnu.org 
Subject: Re: Problems with changing the type of an ssa name

[EXTERNAL EMAIL NOTICE: This email originated from an external sender. Please 
be mindful of safe email handling and proprietary information protection 
practices.]


On July 25, 2020 10:47:59 PM GMT+02:00, Gary Oblock  
wrote:
>Richard,
>
>I suppose that might be doable but aren't there any ramifications
>from the fact that the problematic ssa_names are the default defs?
>I can imagine easily replacing all the ssa names except those that
>are default defs.

Well, just changing the SSA names doesn't make it less ramifications. You have 
to know what you are doing.

So - what's the reason you need to change those SSA name types?

Richard.

>Gary
>
>From: Richard Biener 
>Sent: Friday, July 24, 2020 11:16 PM
>To: Gary Oblock ; Gary Oblock via Gcc
>; gcc@gcc.gnu.org 
>Subject: Re: Problems with changing the type of an ssa name
>
>[EXTERNAL EMAIL NOTICE: This email originated from an external sender.
>Please be mindful of safe email handling and proprietary information
>protection practices.]
>
>
>On July 25, 2020 7:30:48 AM GMT+02:00, Gary Oblock via Gcc
> wrote:
>>If you've followed what I've been up to via my questions
>>on the mailing list, I finally traced my latest big problem
>>back to to my own code. In a nut shell here is what
>>I'm doing.
>>
>>I'm creating a new type exaactly like this:
>>
>>tree pointer_rep =
>>  make_signed_type ( TYPE_PRECISION ( pointer_sized_int_node));
>>TYPE_MAIN_VARIANT ( pointer_rep) =
>>  TYPE_MAIN_VARIANT ( pointer_sized_int_node);
>>const char *gcc_name =
>>identifier_to_locale ( IDENTIFIER_POINTER ( TYPE_NAME (
>>ri->gcc_type)));
>>size_t len =
>>  strlen ( REORG_SP_PTR_PREFIX) + strlen ( gcc_name);
>>char *name = ( char *)alloca(len + 1);
>>strcpy ( name, REORG_SP_PTR_PREFIX);
>>strcat ( name, gcc_name);
>>TYPE_NAME ( pointer_rep) = get_identifier ( name);
>>
>>I detect an ssa_name that I want to change to have this type
>>and change it thusly. Note, this particular ssa_name is a
>>default def which I seems to be very pertinent (since it's
>>the only case that fails.)
>>
>>modify_ssa_name_type ( an_ssa_name, pointer_rep);
>>
>>void
>>modify_ssa_name_type ( tree ssa_name, tree type)
>>{
>>  // This rips off the code in make_ssa_name_fn with a
>>  // modification or two.
>>
>>  if ( TYPE_P ( type) )
>>{
>>   TREE_TYPE ( ssa_name) = TYPE_MAIN_VARIANT ( type);
>>   if ( ssa_defined_default_def_p ( ssa_name) )
>>  {
>> // I guessing which I know is a terrible thing to do...
>> SET_SSA_NAME_VAR_OR_IDENTIFIER ( ssa_name, TYPE_MAIN_VARIANT (
>type));
>>   }
>> else
>>   {
>>   // The following breaks defaults defs hence the check
>above.
>> SET_SSA_NAME_VAR_OR_IDENTIFIER ( ssa_name, NULL_TREE);
>>   }
>>}
>> else
>>{
>>  TREE_TYPE ( ssa_name) = TREE_TYPE ( type);
>>  SET_SSA_NAME_VAR_OR_IDENTIFIER ( ssa_name, type);
>>}
>>}
>>
>>After this it dies when trying to

Re: Gcc Digest, Vol 5, Issue 52

[Gary Oblock via Gcc]

Almost all of the makes sense to.

I'm not sure what a conditionally initialized pointer is.

You mention VAR_DECL but I assume this is for
completeness and not something I'll run across
associated with a default def (but then again I don't
understand notion of a conditionally initialized
pointer.)

I'm at the moment only dealing with a single malloced
array of structures of the given type (though multiple types could have this 
property.) I intend to extend this to cover multiple array and static 
allocations but I need to get the easiest case working first. This means no 
side pointers are needed and if and when I need them pointer will get 
transformed into a base and index pair.

I intend to do the creation of new ssa names as a separate pass from the gimple 
transformations. So I will technically be creating for the duration of the pass 
possibly two defs associated with a single gimple statement. Do I need to 
delete the old ssa names
via some mechanism?

By the way this is really helpful information. The only
other person on the project, Erick, is a continent away
and has about as much experience with gimple as
me but a whole heck lot less compiler experience.

Thanks,

Gary


From: Gcc  on behalf of gcc-requ...@gcc.gnu.org 

Sent: Monday, July 27, 2020 1:33 AM
To: gcc@gcc.gnu.org 
Subject: Gcc Digest, Vol 5, Issue 52

[EXTERNAL EMAIL NOTICE: This email originated from an external sender. Please 
be mindful of safe email handling and proprietary information protection 
practices.]


Send Gcc mailing list submissions to
gcc@gcc.gnu.org

To subscribe or unsubscribe via the World Wide Web, visit
http://gcc.gnu.org/mailman/listinfo/gcc
or, via email, send a message with subject or body 'help' to
gcc-requ...@gcc.gnu.org

You can reach the person managing the list at
gcc-ow...@gcc.gnu.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Gcc digest..."

Re: Gcc Digest, Vol 5, Issue 52

[Gary Oblock via Gcc]

Richard,

I wasn't aware of release_defs so I'll add that for certain.

When I do a single transformation as part of the transformation pass
each transformation uses the correct types internally but on the edges
emits glue code that will be transformed via a dangling type fixup pass.

For example when adding something to a pointer:

_2 = _1 + k

Where _1 & _2 are the old point types I'll
 emit

new_3 = (type_convert)_1
new_4 = (type_convert)k
new_5 = new_4 / struct_size // truncating divide
new_6 = new_3 + new_5
_2   = (type_convert)_new_6

Note, the casting is done with CONVERT_EXPR
which is harmless when I create new ssa names
and set the appropriate operands in

new_3 = (type_convert)_1
_2 = (type_convert)new_6

to

new_3 = new_7
new_8 = new_6

Now I might actually find via a look up that
_1 and/or _2 were already mapped to
new_7 and/or new_8 but that's irrelevant.

To intermix the applications of the transformations and
the patching of these dangling types seems like I'd
need to do an insanely ugly recursive walk of each functions
body.

I'm curious when you mention def-use I'm not aware of
GCC using def-use chains except at the RTL level.
Is there a def-use mechanism in GIMPLE because
in SSA form it's trivial to find the definition of
a temp variable but non trivial to find the use of
it. Which I think is a valid reason for fixing up the
dangling types of temps in a scan.

Note, I'll maintain a mapping like you suggest but not use
it at transformation application time. Furthermore,
I'll initialize the mapping with the default defs from
the DECLs so I won't have to mess with them on the fly.
Now at the time in the scan when I find uses and defs of
a dangling type I'd like to simply modify the associated operands
of the statement. What is the real advantage creating a new
statement with the correct types? I'll be using SSA_NAME_DEF_STMT
if the newly created ssa name is on the left hand side. Also, the
ssa_name it replaces will no longer be referenced by the end of the
scan pass.

Note, I do have a escape mechanism in a qualification
pre-pass to the transformations. It's not intended as
catch-all for things I don't understand rather it's an
aid to find possible new cases. However, there are
legitimate things at this point in time during development
of this optimization that I need to spot things this way. Later,
when points to analysis is integrated falling through to
the default case behavior will likely cause an internal error.

Thanks,

Gary


From: Richard Biener 
Sent: Tuesday, July 28, 2020 12:07 AM
To: Gary Oblock 
Cc: gcc@gcc.gnu.org 
Subject: Re: Gcc Digest, Vol 5, Issue 52

[EXTERNAL EMAIL NOTICE: This email originated from an external sender. Please 
be mindful of safe email handling and proprietary information protection 
practices.]


On Tue, Jul 28, 2020 at 4:36 AM Gary Oblock via Gcc  wrote:
>
> Almost all of the makes sense to.
>
> I'm not sure what a conditionally initialized pointer is.

{
  void *p;
  if (condition)
p = ...;
  if (other condition)
 ... use p;

will end up with a PHI node after the conditional init with
one PHI argument being the default definition SSA name
for 'p'.


> You mention VAR_DECL but I assume this is for
> completeness and not something I'll run across
> associated with a default def (but then again I don't
> understand notion of a conditionally initialized
> pointer.)
>
> I'm at the moment only dealing with a single malloced
> array of structures of the given type (though multiple types could have this 
> property.) I intend to extend this to cover multiple array and static 
> allocations but I need to get the easiest case working first. This means no 
> side pointers are needed and if and when I need them pointer will get 
> transformed into a base and index pair.
>
> I intend to do the creation of new ssa names as a separate pass from the 
> gimple transformations. So I will technically be creating for the duration of 
> the pass possibly two defs associated with a single gimple statement. Do I 
> need to delete the old ssa names
> via some mechanism?

When you remove the old definition do

   gsi_remove (&gsi, true); // gsi points at stmt
   release_defs (stmt);

note that as far as I understand you need to modify the stmts using
the former pointer (since its now an index), and I would not recommend
to make creation of new SSA names a separate pass, instead create
them when you alter the original definition and maintain a map
between old and new SSA name.

I haven't dug deep enough into your figure how you identify things
to modify (well, I fear you're just scanning for "uses" of the changed
type ...), but in the scheme I think should be implemented you'd
follow the SSA def->use links for both tr

Re: Gcc Digest, Vol 5, Issue 52

[Gary Oblock via Gcc]

t; if the newly created ssa name is on the left hand side. Also, the
> ssa_name it replaces will no longer be referenced by the end of the
> scan pass.

Since you are replacing a[i].b with array_for_b[i] I am wondering
how you do the transform for non-pointer adjustments.

> Note, I do have a escape mechanism in a qualification
> pre-pass to the transformations. It's not intended as
> catch-all for things I don't understand rather it's an
> aid to find possible new cases. However, there are
> legitimate things at this point in time during development
> of this optimization that I need to spot things this way. Later,
> when points to analysis is integrated falling through to
> the default case behavior will likely cause an internal error.
>
> Thanks,
>
> Gary
>
> ____
> From: Richard Biener 
> Sent: Tuesday, July 28, 2020 12:07 AM
> To: Gary Oblock 
> Cc: gcc@gcc.gnu.org 
> Subject: Re: Gcc Digest, Vol 5, Issue 52
>
> [EXTERNAL EMAIL NOTICE: This email originated from an external sender. Please 
> be mindful of safe email handling and proprietary information protection 
> practices.]
>
>
> On Tue, Jul 28, 2020 at 4:36 AM Gary Oblock via Gcc  wrote:
> >
> > Almost all of the makes sense to.
> >
> > I'm not sure what a conditionally initialized pointer is.
>
> {
>   void *p;
>   if (condition)
> p = ...;
>   if (other condition)
>  ... use p;
>
> will end up with a PHI node after the conditional init with
> one PHI argument being the default definition SSA name
> for 'p'.
>
>
> > You mention VAR_DECL but I assume this is for
> > completeness and not something I'll run across
> > associated with a default def (but then again I don't
> > understand notion of a conditionally initialized
> > pointer.)
> >
> > I'm at the moment only dealing with a single malloced
> > array of structures of the given type (though multiple types could have 
> > this property.) I intend to extend this to cover multiple array and static 
> > allocations but I need to get the easiest case working first. This means no 
> > side pointers are needed and if and when I need them pointer will get 
> > transformed into a base and index pair.
> >
> > I intend to do the creation of new ssa names as a separate pass from the 
> > gimple transformations. So I will technically be creating for the duration 
> > of the pass possibly two defs associated with a single gimple statement. Do 
> > I need to delete the old ssa names
> > via some mechanism?
>
> When you remove the old definition do
>
>gsi_remove (&gsi, true); // gsi points at stmt
>release_defs (stmt);
>
> note that as far as I understand you need to modify the stmts using
> the former pointer (since its now an index), and I would not recommend
> to make creation of new SSA names a separate pass, instead create
> them when you alter the original definition and maintain a map
> between old and new SSA name.
>
> I haven't dug deep enough into your figure how you identify things
> to modify (well, I fear you're just scanning for "uses" of the changed
> type ...), but in the scheme I think should be implemented you'd
> follow the SSA def->use links for both tracking an objects life
> as well as for modifying the accesses.
>
> With just scanning for types I am quite sure you'll run into
> cases where you discover SSA uses that you did not modify
> because you thought that's not necessary (debug stmts!).  Of
> course you'll simply make more things "type escape points" then.
>
> > By the way this is really helpful information. The only
> > other person on the project, Erick, is a continent away
> > and has about as much experience with gimple as
> > me but a whole heck lot less compiler experience.
> >
> > Thanks,
> >
> > Gary
> >
> > 
> > From: Gcc  on behalf of gcc-requ...@gcc.gnu.org 
> > 
> > Sent: Monday, July 27, 2020 1:33 AM
> > To: gcc@gcc.gnu.org 
> > Subject: Gcc Digest, Vol 5, Issue 52
> >
> > [EXTERNAL EMAIL NOTICE: This email originated from an external sender. 
> > Please be mindful of safe email handling and proprietary information 
> > protection practices.]
> >
> >
> > Send Gcc mailing list submissions to
> > gcc@gcc.gnu.org
> >
> > To subscribe or unsubscribe via the World Wide Web, visit
> > http://gcc.gnu.org/mailman/listinfo/gcc
> > or, via email, send a message with subject or body 'help' to
> > gcc-requ...@gcc.gnu.org
> >
> > You can reach the person managing the list at
> > gcc-ow...@gcc.gnu.org
> >
> > When replying, please edit your Subject line so it is more specific
> > than "Re: Contents of Gcc digest..."

A problem with DECL_FIELD_OFFSET in something I declared

[Gary Oblock via Gcc]

This problem is from my structure reorganization optimization
optimization code (simplified and cleaned to illustrate
the problem.

Here's what happening below at the high level

>From the user program:

typedef struct type type_t;
struct type {
  double x;
  double y;
}:

I'll be creating:

typedef struct type_prime type_prime_t;
struct type_prime {
  double x *;
  double y *;
};

and

type_prime_t base_for_type_prime;

Later, when running partial redundancy elimination,
PRE attempts to access the DECL_FIELD_OFFSET of field
x and finds that the the DECL_FIELD_OFFSET is NULL.

Note, I suppose I could run gdb to track down in the storage
layout code what caused it to bypass place_field (where the
offset probably should be initialized) but I'd still not know
what I'm doing wrong below.

Please, somebody have a look and let me know.

Thanks,

Gary Oblock



// An alternate method of creating a record type
// I tried both ways
#define LANG_HOOKS 1

static void
create_a_new_type_and_base_var ( Info_t *info, tree type)
{
  // For the sake of this code "ri" is just a place with
  // interesting stuff about "type"
  ReorgType_t *ri = get_reorgtype_info ( type, info);
  if ( ri != NULL ) {

#if FROM_HOOKS
tree reorg_type_prime =
  lang_hooks.types.make_type (RECORD_TYPE);
#else
tree reorg_type_prime =
  build_variant_type_copy ( type MEM_STAT_DECL);
#endif

ri->reorg_ver_type = reorg_type_prime;

// Code to create name of reorg_type_prime ... irrelevant
//   :
TYPE_NAME ( reorg_type_prime) = get_identifier ( rec_name);

// Build the new pointer type fields

tree field;
tree new_fields = NULL;
for (
   #if LANG_HOOKS
   field = TYPE_FIELDS ( type);
   #else
   field = TYPE_FIELDS ( reorg_type_prime);
   #endif
   field;
   field = DECL_CHAIN ( field))
  {
 tree tree_type = TREE_TYPE ( field);
 tree new_fld_type = build_pointer_type ( tree_type);
 // I use the same name as the field of type
 tree new_decl =
   build_decl ( DECL_SOURCE_LOCATION (field),
   FIELD_DECL, DECL_NAME (field), new_fld_type);
 DECL_CONTEXT ( new_decl) = reorg_type_prime;
 layout_decl ( new_decl, 0);

 // I might be missing a bunch of attributes (see tree-nested.c:899)

 DECL_CHAIN ( new_decl) = new_fields;
 new_fields = new_decl;
  }

// store reversed fields into reorg_type_prime (having them in the same
// order in as in type makes sense.)
TYPE_FIELDS ( reorg_type_prime) = NULL;
tree next_fld;
for ( field = new_fields; field; field = next_fld)
  {
 next_fld = DECL_CHAIN ( field);
 DECL_CHAIN ( field) = TYPE_FIELDS ( reorg_type_prime);
 TYPE_FIELDS ( reorg_type_prime) = field;
  }
// Fix-up the layout
layout_type ( reorg_type_prime);

// Create the base element for the transformed type.
tree base_var =
  build_decl ( UNKNOWN_LOCATION, VAR_DECL, NULL_TREE, reorg_type_prime);

// More name creation code here... irrelevant
   //:
DECL_NAME ( base_var) = get_identifier ( base_name);

// Some attributes I really don't understand...
TREE_STATIC ( base_var) = 1;
TREE_ADDRESSABLE  ( base_var) = 1;
DECL_NONALIASED ( base_var) = 1;
SET_DECL_ALIGN ( base_var, TYPE_ALIGN ( ri->reorg_ver_type));

// Is this necessary guys???
varpool_node::finalize_decl ( base_var);

relayout_decl ( base_var);

ri->base = base_var;
  }
}




CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for 
the sole use of the intended recipient(s) and contains information that is 
confidential and proprietary to Ampere Computing or its subsidiaries. It is to 
be used solely for the purpose of furthering the parties' business 
relationship. Any review, copying, or distribution of this email (or any 
attachments thereto) is strictly prohibited. If you are not the intended 
recipient, please contact the sender immediately and permanently delete the 
original and any copies of this email and any attachments thereto.

Problem cropping up in Value Range Propogation

[Gary Oblock via Gcc]

I'm trying to debug a problem cropping up in value range propagation.
Ironically I probably own an original copy 1995 copy of the paper it's
based on but that's not going to be much help since I'm lost in the
weeds.  It's running on some optimization (my structure reorg
optimization) generated GIMPLE statements.

Here's the GIMPLE dump:

Function max_of_y (max_of_y, funcdef_no=1, decl_uid=4391, cgraph_uid=2, 
symbol_order=20) (executed once)

max_of_y (unsigned long data, size_t len)
{
  double value;
  double result;
  size_t i;

   [local count: 118111600]:
  field_arry_addr_14 = _reorg_base_var_type_t.y;
  index_15 = (sizetype) data_27(D);
  offset_16 = index_15 * 8;
  field_addr_17 = field_arry_addr_14 + offset_16;
  field_val_temp_13 = MEM  [(void *)field_addr_17];
  result_8 = field_val_temp_13;
  goto ; [100.00%]

   [local count: 955630225]:
  _1 = i_3 * 16;
  PPI_rhs1_cast_18 = (unsigned long) data_27(D);
  PPI_rhs2_cast_19 = (unsigned long) _1;
  PtrPlusInt_Adj_20 = PPI_rhs2_cast_19 / 16;
  PtrPlusInt_21 = PPI_rhs1_cast_18 + PtrPlusInt_Adj_20;
  dedangled_27 = (unsigned long) PtrPlusInt_21;
  field_arry_addr_23 = _reorg_base_var_type_t.y;
  index_24 = (sizetype) dedangled_27;
  offset_25 = index_24 * 8;
  field_addr_26 = field_arry_addr_23 + offset_25;
  field_val_temp_22 = MEM  [(void *)field_addr_26];
  value_11 = field_val_temp_22;
  if (result_5 < value_11)
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 477815112]:

   [local count: 955630225]:
  # result_4 = PHI 
  i_12 = i_3 + 1;

   [local count: 1073741824]:
  # i_3 = PHI <1(2), i_12(5)>
  # result_5 = PHI 
  if (i_3 < len_9(D))
goto ; [89.00%]
  else
goto ; [11.00%]

   [local count: 118111600]:
  # result_10 = PHI 
  return result_10;
}

The failure in VRP is occurring on

offset_16 = data_27(D) * 8;

which is the from two adjacent statements above

  index_15 = (sizetype) data_27(D);
  offset_16 = index_15 * 8;

being merged together.

Note, the types of index_15/16 are sizetype and data_27 is unsigned
long.
The error message is:

internal compiler error: tree check: expected class ‘type’, have ‘exceptional’ 
(error_mark) in to_wide,

Things only start to look broken in value_range::lower_bound in
value-range.cc when

return wi::to_wide (t);

is passed error_mark_node in t. It's getting it from m_min just above.
My observation is that m_min is not always error_mark_node. In fact, I
seem to think you need to use set_varying to get this to even happen.

Note, the ssa_propagation_engine processed the statement "offset_16 =
data..."  multiple times before failing on it. What oh what is
happening and how in the heck did I cause it???

Please, somebody throw me a life preserver on this.

Thanks,

Gary


CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for 
the sole use of the intended recipient(s) and contains information that is 
confidential and proprietary to Ampere Computing or its subsidiaries. It is to 
be used solely for the purpose of furthering the parties' business 
relationship. Any review, copying, or distribution of this email (or any 
attachments thereto) is strictly prohibited. If you are not the intended 
recipient, please contact the sender immediately and permanently delete the 
original and any copies of this email and any attachments thereto.

Silly question about pass numbers

[Gary Oblock via Gcc]

For these two dump files:

exe.ltrans0.ltrans.074i.cp

and

exe.ltrans0.ltrans.087i.structure-reorg

doesn't the ".074i." mean that this dump was created
before the ".087i." dump?

If so then why does the ".074i." show GIMPLE that was
created in the structure-reorg pass?

Thanks,

Gary


CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for 
the sole use of the intended recipient(s) and contains information that is 
confidential and proprietary to Ampere Computing or its subsidiaries. It is to 
be used solely for the purpose of furthering the parties' business 
relationship. Any review, copying, or distribution of this email (or any 
attachments thereto) is strictly prohibited. If you are not the intended 
recipient, please contact the sender immediately and permanently delete the 
original and any copies of this email and any attachments thereto.

Why am I seeing free.2 instead of free in exe.ltrans0.ltrans.s??

[Gary Oblock via Gcc]

Note, I'm getting close to getting my part of the structure reorganization
optimization minimally functional (my question about value range propagation 
remains open since I re-enabled a couple of optimizations to bypass it.) 
Therefore this is actually important for me to resolve.

I obviously generated calls to the standard library function "free."
Also, similar calls to malloc didn't have that ".2" appended on them.
I'd normally handle a problem like this with a Google search but
"free.2" gets turned into "free to" and I get an insane number of
junk search results.

This is obviously an easy question to answer for those that
have seen something similar in the past.

Thanks,

Gary Oblock




CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for 
the sole use of the intended recipient(s) and contains information that is 
confidential and proprietary to Ampere Computing or its subsidiaries. It is to 
be used solely for the purpose of furthering the parties' business 
relationship. Any review, copying, or distribution of this email (or any 
attachments thereto) is strictly prohibited. If you are not the intended 
recipient, please contact the sender immediately and permanently delete the 
original and any copies of this email and any attachments thereto.

Re: Silly question about pass numbers

[Gary Oblock via Gcc]

Segher,

First, thanks for replying.

The files are from the same run:
-rw-rw-r-- 1 gary gary  3855 Aug 12 12:49 exe.ltrans0.ltrans.074i.cp
-rw-rw-r-- 1 gary gary 16747 Aug 12 12:49 
exe.ltrans0.ltrans.087i.structure-reorg

By the time .cp was created inlining results in only main existing.
In the .structure-reorg file there are three functions.

Not only am I seeing things in .cp (beyond a shadow of a doubt)
that were created in structure  reorganization, inlining has also
been done and its pass number of 79!

Note, this is not hurting me in any way other than violating my
beliefs about pass numbering.

Thanks again,

Gary

From: Segher Boessenkool 
Sent: Wednesday, August 12, 2020 1:09 PM
To: Gary Oblock 
Cc: gcc@gcc.gnu.org 
Subject: Re: Silly question about pass numbers

[EXTERNAL EMAIL NOTICE: This email originated from an external sender. Please 
be mindful of safe email handling and proprietary information protection 
practices.]


On Tue, Aug 11, 2020 at 08:27:29PM +, Gary Oblock via Gcc wrote:
> For these two dump files:
>
> exe.ltrans0.ltrans.074i.cp
>
> and
>
> exe.ltrans0.ltrans.087i.structure-reorg
>
> doesn't the ".074i." mean that this dump was created
> before the ".087i." dump?

It means that the 074 pass is earlier than the 087 pass in the pass
pipeline.

> If so then why does the ".074i." show GIMPLE that was
> created in the structure-reorg pass?

Were they created at the same time, or is one of the dump files old?

Are you looking at the same functions?

Etc.


Segher

Re: Silly question about pass numbers

[Gary Oblock via Gcc]

Segher,

If this was on the mainline and not in the middle of a
nontrivial optimization effort I would have filed a bug report
and not asked a silly question. 😉

I'm at a total lost as to how I could have caused the pass
numbers to be backward... but at least have I confirmed that's
what seems to be happening. It's not doing any harm to
anything except the sanity of anybody looking at the pass
dumps...

Thanks,

Gary

From: Segher Boessenkool 
Sent: Wednesday, August 12, 2020 5:45 PM
To: Gary Oblock 
Cc: gcc@gcc.gnu.org 
Subject: Re: Silly question about pass numbers

[EXTERNAL EMAIL NOTICE: This email originated from an external sender. Please 
be mindful of safe email handling and proprietary information protection 
practices.]


Hi!

On Wed, Aug 12, 2020 at 08:26:34PM +, Gary Oblock wrote:
> The files are from the same run:
> -rw-rw-r-- 1 gary gary  3855 Aug 12 12:49 exe.ltrans0.ltrans.074i.cp
> -rw-rw-r-- 1 gary gary 16747 Aug 12 12:49 
> exe.ltrans0.ltrans.087i.structure-reorg
>
> By the time .cp was created inlining results in only main existing.
> In the .structure-reorg file there are three functions.

It does not matter what time the dump files were last opened (or created
or written to).

> Not only am I seeing things in .cp (beyond a shadow of a doubt)
> that were created in structure  reorganization, inlining has also
> been done and its pass number of 79!
>
> Note, this is not hurting me in any way other than violating my
> beliefs about pass numbering.

I cannot check on any of that because this is not in mainline GCC?
It is a lot easier if you ask us about problems we may be able to
reproduce ;-)  Like maybe something with only cp and inline?


Segher

Questions regarding update_stmt and release_ssa_name_fn.

[Gary Oblock via Gcc]

I'm having some major grief with a few related things that I'm try to
do. The mostly revolve around trying to change the type of an SSA name
(which I've given up in favor of creating new SSA names and replacing
the ones I wanted to change.) However, this seems too has its own
issues.

In one problematic case in particular, I'm seeing a sequence like:

foo_3 = mumble_1 op mumble_2

bar_5 = foo_3 op baz_4

when replace foo_3 with foo_4 the (having the needed new type.)

I'm seeing a later verification phase think

bar_5 = foo_4 op baz_4

is still associated with the foo_3.

Should the transformation above be associated with update_stmt and/or
release_ssa_name_fn? And if they are both needed is there a proper
order required.  Note, when I try using them, I'm seeing some malformed
tree operands that die in horrible ways.

By the way, I realize I can probably simply create a new GIMPLE stmt
from scratch to replace the ones I'm modifying but this will cause
some significant code bloat and I want to avoid that if at all
possible.

There is an addition wrinkle to this problem with C code like this

void
whatever ( int x, .. )
{
  :
  x++;
  :
}

I'm seeing x_2 being thought of as default definition in the following
GIMPLE stmt when it's clearly not since it's defined by the statement.

  x_2 = X_1 + 4

My approach has been to simply make the SSA name to replace x_2a
normal SSA name and not a default def. Is this not reasonable and
correct?

Thanks,

Gary Oblock

Gary





CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for 
the sole use of the intended recipient(s) and contains information that is 
confidential and proprietary to Ampere Computing or its subsidiaries. It is to 
be used solely for the purpose of furthering the parties' business 
relationship. Any unauthorized review, copying, or distribution of this email 
(or any attachments thereto) is strictly prohibited. If you are not the 
intended recipient, please contact the sender immediately and permanently 
delete the original and any copies of this email and any attachments thereto.

Re: Questions regarding update_stmt and release_ssa_name_fn.

[Gary Oblock via Gcc]

Richard,

>You need to call update_stmt () if you change SSA operands to
>sth else.

I'm having trouble parsing the "sth else" above. Could you
please rephrase this if it's important to your point. I take
what you mean is if you change any SSA operand to any
statement then update that statement.

Thanks,

Gary

From: Richard Biener 
Sent: Thursday, August 27, 2020 2:04 AM
To: Gary Oblock 
Cc: gcc@gcc.gnu.org 
Subject: Re: Questions regarding update_stmt and release_ssa_name_fn.

[EXTERNAL EMAIL NOTICE: This email originated from an external sender. Please 
be mindful of safe email handling and proprietary information protection 
practices.]


On Wed, Aug 26, 2020 at 11:32 PM Gary Oblock via Gcc  wrote:
>
> I'm having some major grief with a few related things that I'm try to
> do. The mostly revolve around trying to change the type of an SSA name
> (which I've given up in favor of creating new SSA names and replacing
> the ones I wanted to change.) However, this seems too has its own
> issues.
>
> In one problematic case in particular, I'm seeing a sequence like:
>
> foo_3 = mumble_1 op mumble_2
>
> bar_5 = foo_3 op baz_4
>
> when replace foo_3 with foo_4 the (having the needed new type.)
>
> I'm seeing a later verification phase think
>
> bar_5 = foo_4 op baz_4
>
> is still associated with the foo_3.
>
> Should the transformation above be associated with update_stmt and/or
> release_ssa_name_fn? And if they are both needed is there a proper
> order required.  Note, when I try using them, I'm seeing some malformed
> tree operands that die in horrible ways.
>
> By the way, I realize I can probably simply create a new GIMPLE stmt
> from scratch to replace the ones I'm modifying but this will cause
> some significant code bloat and I want to avoid that if at all
> possible.

You need to call update_stmt () if you change SSA operands to
sth else.

> There is an addition wrinkle to this problem with C code like this
>
> void
> whatever ( int x, .. )
> {
>   :
>   x++;
>   :
> }
>
> I'm seeing x_2 being thought of as default definition in the following
> GIMPLE stmt when it's clearly not since it's defined by the statement.
>
>   x_2 = X_1 + 4
>
> My approach has been to simply make the SSA name to replace x_2a
> normal SSA name and not a default def. Is this not reasonable and
> correct?

If x_2 is a default def then the IL isn't correct in the first place.  I doubt
it is that way, btw. - we have verifiers that would blow up if it would.

Richard.

>
> Thanks,
>
> Gary Oblock
>
> Gary
>
>
>
>
>
> CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is 
> for the sole use of the intended recipient(s) and contains information that 
> is confidential and proprietary to Ampere Computing or its subsidiaries. It 
> is to be used solely for the purpose of furthering the parties' business 
> relationship. Any unauthorized review, copying, or distribution of this email 
> (or any attachments thereto) is strictly prohibited. If you are not the 
> intended recipient, please contact the sender immediately and permanently 
> delete the original and any copies of this email and any attachments thereto.

Re: Questions regarding update_stmt and release_ssa_name_fn.

[Gary Oblock via Gcc]

> If x_2 is a default def then the IL isn't correct in the first place.  I doubt
> it is that way, btw. - we have verifiers that would blow up if it would.

Richard,

I'm just sharing this so you can tell me whether or not I'm going
crazy. ;-)

This little function is finding that arr_2 = PHI 
is problematic.

void
wolf_fence (
Info *info // Pass level gobal info (might not use it)
  )
{
  struct cgraph_node *node;

  fprintf( stderr,
  "Wolf Fence: Find wolf for default defs with non nop defines\n");

  FOR_EACH_FUNCTION_WITH_GIMPLE_BODY ( node)
{
  struct function *func = DECL_STRUCT_FUNCTION ( node->decl);
  push_cfun ( func);

  unsigned int len = SSANAMES ( func)->length ();
  for ( unsigned int i = 0; i < len; i++)
{
 tree ssa_name = (*SSANAMES ( func))[i];
 if ( ssa_name == NULL ) continue;
 if ( ssa_defined_default_def_p ( ssa_name) )
   {
 gimple *def_stmt =
SSA_NAME_DEF_STMT ( ssa_name);
 if ( !gimple_nop_p ( def_stmt) )
{
 fprintf ( stderr, "Wolf fence caught :");
 print_gimple_stmt ( stderr, def_stmt, 0);
 gcc_assert (0);
}
   }
   }
pop_cfun ();
}
fprintf( stderr, "Wolf Fence: Didn't find wolf!\n");
}

This is run at the very start of the structure reorg pass
before any of my code did anything at all (except initiate
the structure info with a few flags and the like.)

Here's C code:

- aux.h ---
#include "stdlib.h"
typedef struct type type_t;
struct type {
  double x;
  double y;
};

extern type_t *min_of_x( type_t *, size_t);
- aux.c ---
#include "aux.h"
#include "stdlib.h"

type_t *
min_of_x( type_t *arr, size_t len)
{
  type_t *end_of = arr + len;
  type_t *loc = arr;
  double result = arr->x;
  arr++;
  for( ; arr < end_of ; arr++  ) {
double value = arr->x;
if (  value < result ) {
  result = value;
  loc = arr;
}
  }
  return loc;
}
- main.c --
#include "aux.h"
#include "stdio.h"

int
main(void)
{
  size_t len = 1;
  type_t *data = (type_t *)malloc( len * sizeof(type_t));
  int i;
  for( i = 0; i < len; i++ ) {
data[i].x = drand48();
  }

  type_t *min_x;
  min_x = min_of_x( data, len);

  if ( min_x == 0 ) {
printf("min_x error\n");
exit(-1);
  }

  printf("min_x %e\n" , min_x->x);
}
---
Here's the GIMPLE comining into the structure reoganization pass:

Program:

;; Function min_of_x (min_of_x, funcdef_no=0, decl_uid=4391, cgraph_uid=2, 
symbol_order=23) (executed once)

min_of_x (struct type_t * arr, size_t len)
{
  double value;
  double result;
  struct type_t * loc;
  struct type_t * end_of;

   [local count: 118111600]:
  _1 = len_7(D) * 16;
  end_of_9 = arr_8(D) + _1;
  result_11 = arr_8(D)->x;
  arr_12 = arr_8(D) + 16;
  goto ; [100.00%]

   [local count: 955630225]:
  value_14 = arr_2->x;
  if (result_6 > value_14)
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 477815112]:

   [local count: 955630225]:
  # loc_3 = PHI 
  # result_5 = PHI 
  arr_15 = arr_2 + 16;

   [local count: 1073741824]:
  # arr_2 = PHI 
  # loc_4 = PHI 
  # result_6 = PHI 
  if (arr_2 < end_of_9)
goto ; [89.00%]
  else
goto ; [11.00%]

   [local count: 118111600]:
  # loc_13 = PHI 
  return loc_13;

}



;; Function main (main, funcdef_no=1, decl_uid=4389, cgraph_uid=1, 
symbol_order=5) (executed once)

main ()
{
  struct type_t * min_x;
  int i;
  struct type_t * data;

   [local count: 10737416]:
  data_10 = malloc (16);
  goto ; [100.00%]

   [local count: 1063004409]:
  _1 = _4 * 16;
  _2 = data_10 + _1;
  _3 = drand48 ();
  _2->x = _3;
  i_18 = i_6 + 1;

   [local count: 1073741824]:
  # i_6 = PHI <0(2), i_18(3)>
  _4 = (long unsigned int) i_6;
  if (_4 != 1)
goto ; [99.00%]
  else
goto ; [1.00%]

   [local count: 10737416]:
  min_x_12 = min_of_x (data_10, 1);
  if (min_x_12 == 0B)
goto ; [0.04%]
  else
goto ; [99.96%]

   [local count: 4295]:
  __builtin_puts (&"min_x error"[0]);
  exit (-1);

   [local count: 10733121]:
  _5 = min_x_12->x;
  printf ("min_x %e\n", _5);
  return 0;

}

Am I crazy?

Thanks,

Gary









From: Richard Biener 
Sent: Thursday, August 27, 2020 2:04 AM
To: Gary Oblock 
Cc: gcc@gcc.gnu.org 
Subject: Re: Questions regarding update_stmt and release_ssa_name_fn.

[EXTERNAL EMAIL NOTICE: This email originated from an external sender. Please 
be mindful of safe email handling and proprietary information protection 
practices.]


On Wed, Aug 26, 2020 at 11:32 PM Gary Oblock via Gcc  wrote:
>
> I'm having some major grief with a few related things that I'm try to
&g

Types are confused in inlining

[Gary Oblock via Gcc]

I'm not accusing inlining of having problems but I really
need to understand what's going on in this situation so I can
fix my optimization.

The error given is:
main.c: In function ‘main’:
main.c:5:1: error: non-trivial conversion in ‘ssa_name’
5 | main(void)
  | ^
struct type_t *
unsigned long
_101 = dedangled_97;
during GIMPLE pass: fixup_cfg
etc.
etc.

I put a conditional breakpoint in gdb where both
_101 and dedangled_97 were created and low
and behold they were both set to "unsigned long".
Does anybody have a clue as to how "_101" got
changed from "unsigned long" to "struct type_t *"?
Note, the later is a meaningful type in my program.
I'm trying to replace all instances of the former as
part of structure reorganization optimization.) I should
mention that this GIMPLE stmt is the one that moves
the value computed in an inlined function into the body
of code where the inling took place.

Thanks,

Gary Oblock





CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for 
the sole use of the intended recipient(s) and contains information that is 
confidential and proprietary to Ampere Computing or its subsidiaries. It is to 
be used solely for the purpose of furthering the parties' business 
relationship. Any unauthorized review, copying, or distribution of this email 
(or any attachments thereto) is strictly prohibited. If you are not the 
intended recipient, please contact the sender immediately and permanently 
delete the original and any copies of this email and any attachments thereto.

Re: Types are confused in inlining

[Gary Oblock via Gcc]

>This is absolutely not enough information to guess at the
>issue ;)

That's fair, I was hoping some mad genius out there would confess to a
fubar_adjustment phase that was probably at fault. 😉

>I suggest you break at the return stmt of make_ssa_name_fn
>looking for t->base.u.version == 101 to see where and with
>which type _101 is created, from there watch *&t->typed.type
>in case something adjusts the type.

I did the former but I used ssa_name_nodes_created
instead. Which though harder to get at, is unique.
Regarding the later... I guess... But, at various times (on certain
OS versions of certain machines) watch points have been
at bit dubious. I assume on a recent Ubuntu release
on an Intel I7 core this wouldn't be the case???

Thanks,

Gary

From: Richard Biener 
Sent: Wednesday, September 2, 2020 11:31 PM
To: Gary Oblock 
Cc: gcc@gcc.gnu.org 
Subject: Re: Types are confused in inlining

[EXTERNAL EMAIL NOTICE: This email originated from an external sender. Please 
be mindful of safe email handling and proprietary information protection 
practices.]


On Wed, Sep 2, 2020 at 10:19 PM Gary Oblock via Gcc  wrote:
>
> I'm not accusing inlining of having problems but I really
> need to understand what's going on in this situation so I can
> fix my optimization.
>
> The error given is:
> main.c: In function ‘main’:
> main.c:5:1: error: non-trivial conversion in ‘ssa_name’
> 5 | main(void)
>   | ^
> struct type_t *
> unsigned long
> _101 = dedangled_97;
> during GIMPLE pass: fixup_cfg
> etc.
> etc.
>
> I put a conditional breakpoint in gdb where both
> _101 and dedangled_97 were created and low
> and behold they were both set to "unsigned long".
> Does anybody have a clue as to how "_101" got
> changed from "unsigned long" to "struct type_t *"?
> Note, the later is a meaningful type in my program.
> I'm trying to replace all instances of the former as
> part of structure reorganization optimization.) I should
> mention that this GIMPLE stmt is the one that moves
> the value computed in an inlined function into the body
> of code where the inling took place.

This is absolutely not enough information to guess at the
issue ;)

I suggest you break at the return stmt of make_ssa_name_fn
looking for t->base.u.version == 101 to see where and with
which type _101 is created, from there watch *&t->typed.type
in case something adjusts the type.

> Thanks,
>
> Gary Oblock
>
>
>
>
>
> CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is 
> for the sole use of the intended recipient(s) and contains information that 
> is confidential and proprietary to Ampere Computing or its subsidiaries. It 
> is to be used solely for the purpose of furthering the parties' business 
> relationship. Any unauthorized review, copying, or distribution of this email 
> (or any attachments thereto) is strictly prohibited. If you are not the 
> intended recipient, please contact the sender immediately and permanently 
> delete the original and any copies of this email and any attachments thereto.

A silly question regarding function types

[Gary Oblock via Gcc]

Note, isn't a problem, rather, it's something that puzzles me.

On walking a function types argument types this way

for ( arg = TYPE_ARG_TYPES ( func_type);
   arg != NULL;
   arg = TREE_CHAIN ( arg))
{
   .
   .
 }

I noticed an extra void argument that didn't exist
tagged on the end.

I then noticed other code doing this (which I copied:)

for ( arg = TYPE_ARG_TYPES ( func_type);
arg != NULL && arg != void_list_node;
arg = TREE_CHAIN ( arg))
 {
 .
 .
  }

What is going on here???

Thanks,

Gary



CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for 
the sole use of the intended recipient(s) and contains information that is 
confidential and proprietary to Ampere Computing or its subsidiaries. It is to 
be used solely for the purpose of furthering the parties' business 
relationship. Any unauthorized review, copying, or distribution of this email 
(or any attachments thereto) is strictly prohibited. If you are not the 
intended recipient, please contact the sender immediately and permanently 
delete the original and any copies of this email and any attachments thereto.

A couple GIMPLE questions

[Gary Oblock via Gcc]

First off one of the questions just me being curious but
second is quite serious. Note, this is GIMPLE coming
into my optimization and not something I've modified.

Here's the C code:

type_t *
do_comp( type_t *data, size_t len)
{
  type_t *res;
  type_t *x = min_of_x( data, len);
  type_t *y = max_of_y( data, len);

  res = y;
  if ( x < y ) res = 0;
  return res;
}

And here's the resulting GIMPLE:

;; Function do_comp.constprop (do_comp.constprop.0, funcdef_no=5, 
decl_uid=4392, cgraph_uid=3, symbol_order=68) (executed once)

do_comp.constprop (struct type_t * data)
{
  struct type_t * res;
  struct type_t * x;
  struct type_t * y;
  size_t len;

   [local count: 1073741824]:

   [local count: 1073741824]:
  x_2 = min_of_x (data_1(D), 1);
  y_3 = max_of_y (data_1(D), 1);
  if (x_2 < y_3)
goto ; [29.00%]
  else
goto ; [71.00%]

   [local count: 311385128]:

   [local count: 1073741824]:
  # res_4 = PHI 
  return res_4;

}

The silly question first. In the "if" stmt how does GCC
get those probabilities? Which it shows as 29.00% and
71.00%. I believe they should both be 50.00%.

The serious question is what is going on with this phi?
res_4 = PHI 

This makes zero sense practicality wise to me and how is
it supposed to be recognized and used? Note, I really do
need to transform the "0B" into something else for my
structure reorganization optimization.

Thanks,

Gary Oblock




CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for 
the sole use of the intended recipient(s) and contains information that is 
confidential and proprietary to Ampere Computing or its subsidiaries. It is to 
be used solely for the purpose of furthering the parties' business 
relationship. Any unauthorized review, copying, or distribution of this email 
(or any attachments thereto) is strictly prohibited. If you are not the 
intended recipient, please contact the sender immediately and permanently 
delete the original and any copies of this email and any attachments thereto.

Re: A couple GIMPLE questions

[Gary Oblock via Gcc]

>That's not a question? Are you asking why PHIs exist at all?
>They are the standard way to represent merging in SSA
>representations. You can iterate on the PHIs of a basic block, etc.

Marc,

I first worked with the SSA form twenty years ago so yes I am
aware of what a phi is... I've just never seen a compiler eliminate
an assignment of a variable to a constant and jam the constant into
the phi where the SSA variable should be. What a phi is all about
is representing data flow and a constant in the phi doesn't seem
to be related to that. I can deal with this but it seems that having to
crawl the phis looking for constants seems baroque. I would hope
there is a control that can suppress this or a transformation
that I can invoke to reverse it...

Thanks,

Gary

From: Marc Glisse 
Sent: Saturday, September 5, 2020 11:29 PM
To: Gary Oblock 
Cc: gcc@gcc.gnu.org 
Subject: Re: A couple GIMPLE questions

[EXTERNAL EMAIL NOTICE: This email originated from an external sender. Please 
be mindful of safe email handling and proprietary information protection 
practices.]


On Sat, 5 Sep 2020, Gary Oblock via Gcc wrote:

> First off one of the questions just me being curious but
> second is quite serious. Note, this is GIMPLE coming
> into my optimization and not something I've modified.
>
> Here's the C code:
>
> type_t *
> do_comp( type_t *data, size_t len)
> {
>  type_t *res;
>  type_t *x = min_of_x( data, len);
>  type_t *y = max_of_y( data, len);
>
>  res = y;
>  if ( x < y ) res = 0;
>  return res;
> }
>
> And here's the resulting GIMPLE:
>
> ;; Function do_comp.constprop (do_comp.constprop.0, funcdef_no=5, 
> decl_uid=4392, cgraph_uid=3, symbol_order=68) (executed once)
>
> do_comp.constprop (struct type_t * data)
> {
>  struct type_t * res;
>  struct type_t * x;
>  struct type_t * y;
>  size_t len;
>
>   [local count: 1073741824]:
>
>   [local count: 1073741824]:
>  x_2 = min_of_x (data_1(D), 1);
>  y_3 = max_of_y (data_1(D), 1);
>  if (x_2 < y_3)
>goto ; [29.00%]
>  else
>goto ; [71.00%]
>
>   [local count: 311385128]:
>
>   [local count: 1073741824]:
>  # res_4 = PHI 
>  return res_4;
>
> }
>
> The silly question first. In the "if" stmt how does GCC
> get those probabilities? Which it shows as 29.00% and
> 71.00%. I believe they should both be 50.00%.

See the profile_estimate pass dump. One branch makes the function return
NULL, which makes gcc guess that it may be a bit less likely than the
other. Those are heuristics, which are tuned to help on average, but of
course they are sometimes wrong.

> The serious question is what is going on with this phi?
>res_4 = PHI 
>
> This makes zero sense practicality wise to me and how is
> it supposed to be recognized and used? Note, I really do
> need to transform the "0B" into something else for my
> structure reorganization optimization.

That's not a question? Are you asking why PHIs exist at all? They are the
standard way to represent merging in SSA representations. You can iterate
on the PHIs of a basic block, etc.

> CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is 
> for the sole use of the intended recipient(s) and contains information that 
> is confidential and proprietary to Ampere Computing or its subsidiaries. It 
> is to be used solely for the purpose of furthering the parties' business 
> relationship. Any unauthorized review, copying, or distribution of this email 
> (or any attachments thereto) is strictly prohibited. If you are not the 
> intended recipient, please contact the sender immediately and permanently 
> delete the original and any copies of this email and any attachments thereto.

Could you please get rid of this when posting on public mailing lists?

--
Marc Glisse

Re: A couple GIMPLE questions

[Gary Oblock via Gcc]

>Could you please get rid of this when posting on public mailing lists?

No, I  have no control over that but I'll give the email of our corporate
IT if you want to complain to them...


From: Marc Glisse 
Sent: Saturday, September 5, 2020 11:29 PM
To: Gary Oblock 
Cc: gcc@gcc.gnu.org 
Subject: Re: A couple GIMPLE questions

[EXTERNAL EMAIL NOTICE: This email originated from an external sender. Please 
be mindful of safe email handling and proprietary information protection 
practices.]


On Sat, 5 Sep 2020, Gary Oblock via Gcc wrote:

> First off one of the questions just me being curious but
> second is quite serious. Note, this is GIMPLE coming
> into my optimization and not something I've modified.
>
> Here's the C code:
>
> type_t *
> do_comp( type_t *data, size_t len)
> {
>  type_t *res;
>  type_t *x = min_of_x( data, len);
>  type_t *y = max_of_y( data, len);
>
>  res = y;
>  if ( x < y ) res = 0;
>  return res;
> }
>
> And here's the resulting GIMPLE:
>
> ;; Function do_comp.constprop (do_comp.constprop.0, funcdef_no=5, 
> decl_uid=4392, cgraph_uid=3, symbol_order=68) (executed once)
>
> do_comp.constprop (struct type_t * data)
> {
>  struct type_t * res;
>  struct type_t * x;
>  struct type_t * y;
>  size_t len;
>
>   [local count: 1073741824]:
>
>   [local count: 1073741824]:
>  x_2 = min_of_x (data_1(D), 1);
>  y_3 = max_of_y (data_1(D), 1);
>  if (x_2 < y_3)
>goto ; [29.00%]
>  else
>goto ; [71.00%]
>
>   [local count: 311385128]:
>
>   [local count: 1073741824]:
>  # res_4 = PHI 
>  return res_4;
>
> }
>
> The silly question first. In the "if" stmt how does GCC
> get those probabilities? Which it shows as 29.00% and
> 71.00%. I believe they should both be 50.00%.

See the profile_estimate pass dump. One branch makes the function return
NULL, which makes gcc guess that it may be a bit less likely than the
other. Those are heuristics, which are tuned to help on average, but of
course they are sometimes wrong.

> The serious question is what is going on with this phi?
>res_4 = PHI 
>
> This makes zero sense practicality wise to me and how is
> it supposed to be recognized and used? Note, I really do
> need to transform the "0B" into something else for my
> structure reorganization optimization.

That's not a question? Are you asking why PHIs exist at all? They are the
standard way to represent merging in SSA representations. You can iterate
on the PHIs of a basic block, etc.

> CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is 
> for the sole use of the intended recipient(s) and contains information that 
> is confidential and proprietary to Ampere Computing or its subsidiaries. It 
> is to be used solely for the purpose of furthering the parties' business 
> relationship. Any unauthorized review, copying, or distribution of this email 
> (or any attachments thereto) is strictly prohibited. If you are not the 
> intended recipient, please contact the sender immediately and permanently 
> delete the original and any copies of this email and any attachments thereto.

Could you please get rid of this when posting on public mailing lists?

--
Marc Glisse

Dominance information problem

[Gary Oblock via Gcc]

I'm trying to do performance qualification for my structure
reorganization optimization.

I'm doing pretty straightforward stuff and I haven't at this point in
time (qualifying the optimization,) modified the program. So I'm a
little surprised this is failing.  Here is the code that's failing on
the first iteration of the for loops:

  struct cgraph_node *node;
  FOR_EACH_FUNCTION_WITH_GIMPLE_BODY ( node)  {
struct function *func = DECL_STRUCT_FUNCTION ( node->decl);
push_cfun ( func);

class loop *loop;
FOR_EACH_LOOP_FN ( func, loop, LI_ONLY_INNERMOST )
  {
size_t num_bbs = loop->num_nodes;
basic_block *bbs = get_loop_body ( loop); // FAILS HERE!!!
:
stuff never reached

How it's failing (in code from dominance.c) I'm guessing tells me the
dominance information is messed up (unlikely) or needs to be
recomputed. If I'm not wrong, how do I go about doing the later

/* Return TRUE in case BB1 is dominated by BB2.  */
bool
dominated_by_p (enum cdi_direction dir, const_basic_block bb1, 
const_basic_block bb2)
{
  unsigned int dir_index = dom_convert_dir_to_idx (dir);
  struct et_node *n1 = bb1->dom[dir_index], *n2 = bb2->dom[dir_index];

  gcc_checking_assert (dom_computed[dir_index]); // <=== BOOM!

  if (dom_computed[dir_index] == DOM_OK)
return (n1->dfs_num_in >= n2->dfs_num_in
 && n1->dfs_num_out <= n2->dfs_num_out);

  return et_below (n1, n2);
}


Thanks,

Gary Oblock






CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for 
the sole use of the intended recipient(s) and contains information that is 
confidential and proprietary to Ampere Computing or its subsidiaries. It is to 
be used solely for the purpose of furthering the parties' business 
relationship. Any unauthorized review, copying, or distribution of this email 
(or any attachments thereto) is strictly prohibited. If you are not the 
intended recipient, please contact the sender immediately and permanently 
delete the original and any copies of this email and any attachments thereto.

Re: Dominance information problem

[Gary Oblock via Gcc]

Erick,

I assume that this needs to be done on all the functions since
you mention "cfun".

Gary

From: Erick Ochoa 
Sent: Monday, September 14, 2020 12:10 AM
To: Gary Oblock ; gcc@gcc.gnu.org 
Subject: Re: Dominance information problem

[EXTERNAL EMAIL NOTICE: This email originated from an external sender. Please 
be mindful of safe email handling and proprietary information protection 
practices.]


Hi Gary,

I'm not 100% sure this will fix the problem, but in the past I have had
to call the following function:

   /* If dominator info is not available, we need to calculate it.  */
   if (!dom_info_available_p (CDI_DOMINATORS))
 calculate_dominance_info (CDI_DOMINATORS);

Basically dominance information was not available for cfun.
Also, you might also need to call:

   if (dom_info_available_p (CDI_DOMINATORS))
 free_dominance_info (CDI_DOMINATORS);

Just before your pass is done. These were some calls I needed to make in
a different pass when I was working with dominators.

On 12/09/2020 09:26, Gary Oblock wrote:
> I'm trying to do performance qualification for my structure
> reorganization optimization.
>
> I'm doing pretty straightforward stuff and I haven't at this point in
> time (qualifying the optimization,) modified the program. So I'm a
> little surprised this is failing.  Here is the code that's failing on
> the first iteration of the for loops:
>
>struct cgraph_node *node;
>FOR_EACH_FUNCTION_WITH_GIMPLE_BODY ( node)  {
>  struct function *func = DECL_STRUCT_FUNCTION ( node->decl);
>  push_cfun ( func);
>
>  class loop *loop;
>  FOR_EACH_LOOP_FN ( func, loop, LI_ONLY_INNERMOST )
>{
>  size_t num_bbs = loop->num_nodes;
>  basic_block *bbs = get_loop_body ( loop); // FAILS HERE!!!
>  :
>  stuff never reached
>
> How it's failing (in code from dominance.c) I'm guessing tells me the
> dominance information is messed up (unlikely) or needs to be
> recomputed. If I'm not wrong, how do I go about doing the later
>
> /* Return TRUE in case BB1 is dominated by BB2.  */
> bool
> dominated_by_p (enum cdi_direction dir, const_basic_block bb1, 
> const_basic_block bb2)
> {
>unsigned int dir_index = dom_convert_dir_to_idx (dir);
>struct et_node *n1 = bb1->dom[dir_index], *n2 = bb2->dom[dir_index];
>
>gcc_checking_assert (dom_computed[dir_index]); // <=== BOOM!
>
>if (dom_computed[dir_index] == DOM_OK)
>  return (n1->dfs_num_in >= n2->dfs_num_in
>   && n1->dfs_num_out <= n2->dfs_num_out);
>
>return et_below (n1, n2);
> }
>
>
> Thanks,
>
> Gary Oblock
>
>
>
>
>
>
> CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is 
> for the sole use of the intended recipient(s) and contains information that 
> is confidential and proprietary to Ampere Computing or its subsidiaries. It 
> is to be used solely for the purpose of furthering the parties' business 
> relationship. Any unauthorized review, copying, or distribution of this email 
> (or any attachments thereto) is strictly prohibited. If you are not the 
> intended recipient, please contact the sender immediately and permanently 
> delete the original and any copies of this email and any attachments thereto.
>

Re: How to check reachable between blocks

[Gary Oblock via Gcc]

Andrew,

Dominance and reachability are two different but related things. It's trivial 
to come up with a simple example to show this.

Gary

From: Andrew Pinski 
Sent: Friday, October 9, 2020 8:13 PM
To: Jojo R 
Cc: GCC Development 
Subject: Re: How to check reachable between blocks

On Fri, Oct 9, 2020 at 8:01 PM Jojo R  wrote:
>
> Hi,
>
> Is there any API or common codes to check any two blocks is reachable 
> ?

Yes the API in dominance.h.
Depending on where you use it, you might need to have it created.
Using calculate_dominance_info function.
The function to do the check is dominated_by_p.

Thanks,
Andrew Pinski


>
> Thanks.
>
> Jojo

Where did my function go?

[Gary Oblock via Gcc]

I have a tiny program composed of a few functions
and one of those functions (setupB) has gone missing.
Since I need to walk its GIMPLE, this is a problem.

The program:

-- aux.h -
#include "stdlib.h"
typedef struct A A_t;
typedef struct A B_t;
struct A {
  int i;
  double x;
};

#define MAX(x,y) ((x)>(y) ? (x) : (y))

extern int max1( A_t *, size_t);
extern double max2( B_t *, size_t);
extern A_t *setupA( size_t);
extern B_t *setupB( size_t);
-- aux.c 
#include "aux.h"
#include "stdlib.h"

A_t *
setupA( size_t size)
{
  A_t *data = (A_t *)malloc( size * sizeof(A_t));
  size_t i;
  for( i = 0; i < size; i++ ) {
data[i].i = rand();
data[i].x = drand48();
  }
  return data;
}

B_t *
setupB( size_t size)
{
  B_t *data = (B_t *)malloc( size * sizeof(B_t));
  size_t i;
  for( i = 0; i < size; i++ ) {
data[i].i = rand();
data[i].x = drand48();
  }
  return data;
}

int
max1( A_t *array, size_t len)
{
  size_t i;
  int result = array[0].i;
  for( i = 1; i < len; i++  ) {
result = MAX( array[i].i, result);
  }
  return result;
}

double
max2( B_t *array, size_t len)
{
  size_t i;
  double result = array[0].x;
  for( i = 1; i < len; i++  ) {
result = MAX( array[i].x, result);
  }
  return result;
}
-- main.c -
#include "stdio.h"

A_t *data1;

int
main(void)
{
  B_t *data2 = setupB(200);
  data1 = setupA(100);

  printf("First %d\n" , max1(data1,100));
  printf("Second %e\n", max2(data2,200));
}


Here is its GIMPLE dump:
(for the sole purpose of letting you see
with your own eyes that setupB is indeed missing)

Program:
  static struct A_t * data1;
struct A_t *  (size_t)

;; Function setupA (setupA, funcdef_no=4, decl_uid=4398, cgraph_uid=6, 
symbol_order=48) (executed once)

setupA (size_t size)
{
  size_t i;
  struct A_t * data;

   [local count: 118111600]:
  _1 = size_8(D) * 16;
  data_11 = malloc (_1);
  goto ; [100.00%]

   [local count: 955630225]:
  _2 = i_6 * 16;
  _3 = data_11 + _2;
  _4 = rand ();
  _3->i = _4;
  _5 = drand48 ();
  _3->x = _5;
  i_16 = i_6 + 1;

   [local count: 1073741824]:
  # i_6 = PHI <0(2), i_16(3)>
  if (i_6 < size_8(D))
goto ; [89.00%]
  else
goto ; [11.00%]

   [local count: 118111600]:
  return data_11;

}


int  (struct A_t *)

;; Function max1.constprop (max1.constprop.0, funcdef_no=1, decl_uid=4397, 
cgraph_uid=5, symbol_order=58) (executed once)

max1.constprop (struct A_t * array)
{
  size_t i;
  int result;
  size_t len;

   [local count: 118111600]:

   [local count: 118111600]:
  result_2 = array_1(D)->i;
  goto ; [100.00%]

   [local count: 955630225]:
  _4 = i_3 * 16;
  _5 = array_1(D) + _4;
  _6 = _5->i;
  result_8 = MAX_EXPR <_6, result_7>;
  i_9 = i_3 + 1;

   [local count: 1073741824]:
  # i_3 = PHI <1(2), i_9(3)>
  # result_7 = PHI 
  if (i_3 <= 99)
goto ; [89.00%]
  else
goto ; [11.00%]

   [local count: 118111600]:
  # result_10 = PHI 
  return result_10;

}


double  (struct B_t *)

;; Function max2.constprop (max2.constprop.0, funcdef_no=3, decl_uid=4395, 
cgraph_uid=3, symbol_order=59) (executed once)

max2.constprop (struct B_t * array)
{
  size_t i;
  double result;
  size_t len;

   [local count: 118111600]:

   [local count: 118111600]:
  result_2 = array_1(D)->x;
  goto ; [100.00%]

   [local count: 955630225]:
  _4 = i_3 * 16;
  _5 = array_1(D) + _4;
  _6 = _5->x;
  if (_6 > result_7)
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 477815112]:

   [local count: 955630225]:
  # _10 = PHI 
  i_8 = i_3 + 1;

   [local count: 1073741824]:
  # i_3 = PHI <1(2), i_8(5)>
  # result_7 = PHI 
  if (i_3 <= 199)
goto ; [89.00%]
  else
goto ; [11.00%]

   [local count: 118111600]:
  # result_9 = PHI 
  return result_9;

}


int  (void)

;; Function main (main, funcdef_no=5, decl_uid=4392, cgraph_uid=1, 
symbol_order=25) (executed once)

main ()
{
  struct B_t * data2;

   [local count: 1073741824]:
  data2_6 = setupB (200);
  _1 = setupA (100);
  data1 = _1;
  _2 = max1 (_1, 100);
  printf ("First %d\n", _2);
  _3 = max2 (data2_6, 200);
  printf ("Second %e\n", _3);
  return 0;

}

The pass is invoked at this location in passes.def

  /* Simple IPA passes executed after the regular passes.  In WHOPR mode the
 passes are executed after partitioning and thus see just parts of the
 compiled unit.  */
  INSERT_PASSES_AFTER (all_late_ipa_passes)
  NEXT_PASS (pass_materialize_all_clones);
  NEXT_PASS (pass_ipa_type_escape_analysis);
  NEXT_PASS (pass_ipa_structure_reorg); <== my pass!
  NEXT_PASS (pass_ipa_prototype);
  NEXT_PASS (pass_ipa_pta);
  NEXT_PASS (pass_omp_simd_clone);
  TERMINATE_PASS_LIST (all_late_ipa_passes)

--
The program was compiled with these opt

Re: Where did my function go?

[Gary Oblock via Gcc]

>IPA transforms happens when get_body is called.  With LTO this also
>trigger reading the body from disk.  So if you want to see all bodies
>and work on them, you can simply call get_body on everything but it will
>result in increased memory use since everything will be loaded form disk
>and expanded (by inlining) at once instead of doing it on per-function
>basis.
Jan,

Doing

FOR_EACH_FUNCTION_WITH_GIMPLE_BODY ( node) node->get_body ();

instead of

FOR_EACH_FUNCTION_WITH_GIMPLE_BODY ( node) node->get_untransformed_body ();

instantaneously breaks everything...

Am I missing something?

Gary

From: Jan Hubicka 
Sent: Tuesday, October 20, 2020 4:34 AM
To: Richard Biener 
Cc: GCC Development ; Gary Oblock 
Subject: Re: Where did my function go?

[EXTERNAL EMAIL NOTICE: This email originated from an external sender. Please 
be mindful of safe email handling and proprietary information protection 
practices.]


> > On Tue, Oct 20, 2020 at 1:02 PM Martin Jambor  wrote:
> > >
> > > Hi,
> > >
> > > On Tue, Oct 20 2020, Richard Biener wrote:
> > > > On Mon, Oct 19, 2020 at 7:52 PM Gary Oblock  
> > > > wrote:
> > > >>
> > > >> Richard,
> > > >>
> > > >> I guess that will work for me. However, since it
> > > >> was decided to remove an identical function,
> > > >> why weren't the calls to it adjusted to reflect it?
> > > >> If the call wasn't transformed that means it will
> > > >> be mapped at some later time. Is that mapping
> > > >> available to look at? Because using that would
> > > >> also be a potential solution (assuming call
> > > >> graph information exists for the deleted function.)
> > > >
> > > > I'm not sure how the transitional cgraph looks like
> > > > during WPA analysis (which is what we're talking about?),
> > > > but definitely the IL is unmodified in that state.
> > > >
> > > > Maybe Martin has an idea.
> > > >
> > >
> > > Exactly, the cgraph_edges is where the correct call information is
> > > stored until the inlining transformation phase calls
> > > cgraph_edge::redirect_call_stmt_to_callee is called on it - inlining is
> > > a special pass in this regard that performs this IPA-infrastructure
> > > function in addition to actual inlining.
> > >
> > > In cgraph means the callee itself but also information in
> > > e->callee->clone.param_adjustments which might be interesting for any
> > > struct-reorg-like optimizations (...and in future possibly in other
> > > transformation summaries).
> > >
> > > The late IPA passes are in very unfortunate spot here since they run
> > > before the real-IPA transformation phases but after unreachable node
> > > removals and after clone materializations and so can see some but not
> > > all of the changes performed by real IPA passes.  The reason for that is
> > > good cache locality when late IPA passes are either not run at all or
> > > only look at small portion of the compilation unit.  In such case IPA
> > > transformations of a function are followed by all the late passes
> > > working on the same function.
> > >
> > > Late IPA passes are unfortunately second class citizens and I would
> > > strongly recommend not to use them since they do not fit into our
> > > otherwise robust IPA framework very well.  We could probably provide a
> > > mechanism that would allow late IPA passes to run all normal IPA
> > > transformations on a function so they could clearly see what they are
> > > looking at, but extensive use would slow compilation down so its use
> > > would be frowned upon at the very least.
> >
> > So IPA PTA does get_body () on the nodes it wants to analyze and I
> > thought that triggers any pending IPA transforms?
>
> Yes, it does (and get_untransormed_body does not)
And to bit correct Maritn's explanation: the late IPA passes are
intended to work, though I was mostly planning them for prototyping true
ipa passes and also possibly for implementing passes that inspect only
few functions.

IPA transforms happens when get_body is called.  With LTO this also
trigger reading the body from disk.  So if you want to see all bodies
and work on them, you can simply call get_body on everything but it will
result in increased memory use since everything will be loaded form disk
and expanded (by inlining) at once instead of doing it on per-function
basis.

get_body is simply mean to arrange the body on demand.  The passmanager
uses it before late passes are executed and ipa-pta uses it before it
builds constraints (that is not good for reasons described above).

Clone materialization is also triggered by get_body. The clone
materialization pass mostly happens to remove unreachable function
bodies. I plan to get rid of it, since as we are now better on doing ipa
transforms it brings in a lot of bodies already. For cc1plus it is well
over 1GB of memory.

Honza
>
> Honza
> >
> > Richard.
> >
> > > Martin
> > >

Missing functionality

[Gary Oblock via Gcc]

I'm finishing up coding my patterns for the structure reorganization
optimization. They recognize certain instructions and replace them
other instructions. I've got some code that generates gimple which is
inserted as it's created with gsi_insert_before.  This code is
something I'd like to use at other points in my optimization so I'd
like to create a function to do this.

Now comes the interesting bit. I'd like to use gimple sequences and
after reading the internals documentation I put together something
using gimple_seq_add_stmt to add the generated gimple to a new
sequence. After this I tried inserting the sequence into the basic
block's sequence with gsi_link_seq_before. It turns out there is no
gsi_link_seq_before! I could probably write one myself but that begs
the question, why is there no gsi_link_seq_before and what should I
use instead?

Thank

Gary


CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for 
the sole use of the intended recipient(s) and contains information that is 
confidential and proprietary to Ampere Computing or its subsidiaries. It is to 
be used solely for the purpose of furthering the parties' business 
relationship. Any unauthorized review, copying, or distribution of this email 
(or any attachments thereto) is strictly prohibited. If you are not the 
intended recipient, please contact the sender immediately and permanently 
delete the original and any copies of this email and any attachments thereto.

Regarding last question

[Gary Oblock via Gcc]

Never mind... assume I'm grumbling about the documentation.

;-(

Gary


CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for 
the sole use of the intended recipient(s) and contains information that is 
confidential and proprietary to Ampere Computing or its subsidiaries. It is to 
be used solely for the purpose of furthering the parties' business 
relationship. Any unauthorized review, copying, or distribution of this email 
(or any attachments thereto) is strictly prohibited. If you are not the 
intended recipient, please contact the sender immediately and permanently 
delete the original and any copies of this email and any attachments thereto.

Re: Missing functionality

[Gary Oblock via Gcc]

> gsi_insert_seq_before

Yes, I discovered this myself via Google and ironically it was because of a 
2008 comment by you that you'd renamed gsi_link_seq_before. Frankly, I find 
this a bit amusing. This doesn't seem to be a very heavily used function and 
I'm probably going to be its user.

Gary

From: Richard Biener 
Sent: Thursday, October 22, 2020 11:01 PM
To: Gary Oblock 
Cc: gcc@gcc.gnu.org 
Subject: Re: Missing functionality

[EXTERNAL EMAIL NOTICE: This email originated from an external sender. Please 
be mindful of safe email handling and proprietary information protection 
practices.]


On Fri, Oct 23, 2020 at 5:10 AM Gary Oblock via Gcc  wrote:
>
> I'm finishing up coding my patterns for the structure reorganization
> optimization. They recognize certain instructions and replace them
> other instructions. I've got some code that generates gimple which is
> inserted as it's created with gsi_insert_before.  This code is
> something I'd like to use at other points in my optimization so I'd
> like to create a function to do this.
>
> Now comes the interesting bit. I'd like to use gimple sequences and
> after reading the internals documentation I put together something
> using gimple_seq_add_stmt to add the generated gimple to a new
> sequence. After this I tried inserting the sequence into the basic
> block's sequence with gsi_link_seq_before. It turns out there is no
> gsi_link_seq_before! I could probably write one myself but that begs
> the question, why is there no gsi_link_seq_before and what should I
> use instead?

gsi_insert_seq_before

> Thank
>
> Gary
>
>
> CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is 
> for the sole use of the intended recipient(s) and contains information that 
> is confidential and proprietary to Ampere Computing or its subsidiaries. It 
> is to be used solely for the purpose of furthering the parties' business 
> relationship. Any unauthorized review, copying, or distribution of this email 
> (or any attachments thereto) is strictly prohibited. If you are not the 
> intended recipient, please contact the sender immediately and permanently 
> delete the original and any copies of this email and any attachments thereto.

gsi_remove on a call

[Gary Oblock via Gcc]

I'm running into grief in verify_node in cgraph.c
when I use gsi_remove on a call statement.

Specifically it's a free statement which I've replaced
with other free statements as part of my structure
reorg optimizations. Note, in other working code
I do this with malloc and it doesn't seem to be a problem.

Where it happens it's trying to look at the call graph edges.
Is there a way to remove the edge in question or mark it
to be ignored? I see that line below about built in unreachable
and wonder if I'm supposed to set the decl to that but I
don't see others doing it so...

Here's the code in cgraph (e->call_stmt is the free in question:)

 if (gimple_has_body_p (e->caller->decl)
 && !e->caller->inlined_to
 && !e->speculative
 /* Optimized out calls are redirected to __builtin_unreachable.  */
 && (e->count.nonzero_p ()
 || ! e->callee->decl
 || !fndecl_built_in_p (e->callee->decl, BUILT_IN_UNREACHABLE))
 && count == ENTRY_BLOCK_PTR_FOR_FN(DECL_STRUCT_FUNCTION  (decl))->count
&& (!e->count.ipa_p ()
 && e->count.differs_from_p (gimple_bb (e->call_stmt)->count)))
   {
  :

Thanks,

Gary






CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for 
the sole use of the intended recipient(s) and contains information that is 
confidential and proprietary to Ampere Computing or its subsidiaries. It is to 
be used solely for the purpose of furthering the parties' business 
relationship. Any unauthorized review, copying, or distribution of this email 
(or any attachments thereto) is strictly prohibited. If you are not the 
intended recipient, please contact the sender immediately and permanently 
delete the original and any copies of this email and any attachments thereto.

Re: gsi_remove on a call

[Gary Oblock via Gcc]

Martin,

After some digging and a little luck, I found that this does what I wanted:

cgraph_update_edges_for_call_stmt ( stmt, gimple_call_fndecl ( stmt), NULL);

Thanks,

Gary

From: Martin Jambor 
Sent: Tuesday, October 27, 2020 5:44 AM
To: Gary Oblock ; gcc@gcc.gnu.org 
Subject: Re: gsi_remove on a call

[EXTERNAL EMAIL NOTICE: This email originated from an external sender. Please 
be mindful of safe email handling and proprietary information protection 
practices.]


On Tue, Oct 27 2020, Gary Oblock via Gcc wrote:
> I'm running into grief in verify_node in cgraph.c
> when I use gsi_remove on a call statement.
>
> Specifically it's a free statement which I've replaced
> with other free statements as part of my structure
> reorg optimizations. Note, in other working code
> I do this with malloc and it doesn't seem to be a problem.
>
> Where it happens it's trying to look at the call graph edges.
> Is there a way to remove the edge in question or mark it
> to be ignored?

Have you tried using cgraph_edge::set_call_stmt to update the edge?

> I see that line below about built in unreachable
> and wonder if I'm supposed to set the decl to that but I
> don't see others doing it so...

The comment you quoted explains why __builtin_unreachable is special.

Martin

>
> Here's the code in cgraph (e->call_stmt is the free in question:)
>
>  if (gimple_has_body_p (e->caller->decl)
>  && !e->caller->inlined_to
>  && !e->speculative
>  /* Optimized out calls are redirected to __builtin_unreachable.  */
>  && (e->count.nonzero_p ()
>  || ! e->callee->decl
>  || !fndecl_built_in_p (e->callee->decl, BUILT_IN_UNREACHABLE))
>  && count == ENTRY_BLOCK_PTR_FOR_FN(DECL_STRUCT_FUNCTION  (decl))->count
> && (!e->count.ipa_p ()
>  && e->count.differs_from_p (gimple_bb (e->call_stmt)->count)))
>{
>   :
>
> Thanks,
>
> Gary
>
>
>
>
>
>
> CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is 
> for the sole use of the intended recipient(s) and contains information that 
> is confidential and proprietary to Ampere Computing or its subsidiaries. It 
> is to be used solely for the purpose of furthering the parties' business 
> relationship. Any unauthorized review, copying, or distribution of this email 
> (or any attachments thereto) is strictly prohibited. If you are not the 
> intended recipient, please contact the sender immediately and permanently 
> delete the original and any copies of this email and any attachments thereto.

A problem with field decl offsets in newly minted types

[Gary Oblock via Gcc]

I'm having some grief with creating/using some modified types.

I problem occurs in tree-ssa-sccvn.c when some code tries
to take a DECL_FIELD_OFFSET and unfortuenately gets a null
that causes a crash.

So, I traced this back the to types I created. Note, the method I used
has seemed to be fairly robust (some other engineers in our China
group even successfully copied it for thier own optimization.)
However, the DECL_FIELD_OFFSET offset is definitely null for
the fields which I created in the new versions of the types.

Here is what I'm doing.

tree type_prime = lang_hooks.types.make_type (RECORD_TYPE);

const char *base_type_name =
  identifier_to_locale ( IDENTIFIER_POINTER ( TYPE_NAME ( type)));
size_t len = strlen ( MY_PREFIX) + strlen ( base_type_name);
char *rec_name = ( char*)alloca ( len + 1);
strcpy ( rec_name, MY_PREFIX);
strcat ( rec_name, base_type_name);

TYPE_NAME ( reorg_type_prime) = get_identifier ( rec_name);

tree field;
tree new_fields = NULL;
for ( field = TYPE_FIELDS ( type); field; field = DECL_CHAIN ( field))
  {
// Probably useful in creating the new field type.
tree old_fld_type = TREE_TYPE ( field);

// Whatever you want the new field type to be
tree new_fld_type = ...;
tree new_decl =
  build_decl ( DECL_SOURCE_LOCATION (field),
  FIELD_DECL, DECL_NAME (field), new_fld_type);
 DECL_CONTEXT ( new_decl) = type_prime;
 layout_decl ( new_decl, 0);
 DECL_CHAIN ( new_decl) = new_fields;
 new_fields = new_decl;
  }

TYPE_FIELDS ( type_prime) = nreverse ( new_fields);
layout_type ( type_prime);

Note, when I change any declaration to have a modified type
I run relayout_decl on them.

If somebody could please tell what bit I'm missing or what I'm doing
wrong I'd really appreciate it. Looking at the code in layout_type,
it should be setting the decl field offsets with place_field and I
don't have a clue what's going on.

Thanks,

Gary


CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for 
the sole use of the intended recipient(s) and contains information that is 
confidential and proprietary to Ampere Computing or its subsidiaries. It is to 
be used solely for the purpose of furthering the parties' business 
relationship. Any unauthorized review, copying, or distribution of this email 
(or any attachments thereto) is strictly prohibited. If you are not the 
intended recipient, please contact the sender immediately and permanently 
delete the original and any copies of this email and any attachments thereto.

Re: A problem with field decl offsets in newly minted types

[Gary Oblock via Gcc]

The offsets seem to actually be created. However,
they are almost immediately are being deleted.

Any ideas what's going on? Has some kind
of memory management gizmo gone awry?

Gary

PS For anybody who has been following my travails with the instance 
interleaving structure
reorganization optimization, this is occurring
with the Mcf sources from SPEC17.


From: Gary Oblock 
Sent: Wednesday, December 30, 2020 11:00 PM
To: gcc@gcc.gnu.org 
Subject: A problem with field decl offsets in newly minted types

I'm having some grief with creating/using some modified types.

I problem occurs in tree-ssa-sccvn.c when some code tries
to take a DECL_FIELD_OFFSET and unfortuenately gets a null
that causes a crash.

So, I traced this back the to types I created. Note, the method I used
has seemed to be fairly robust (some other engineers in our China
group even successfully copied it for thier own optimization.)
However, the DECL_FIELD_OFFSET offset is definitely null for
the fields which I created in the new versions of the types.

Here is what I'm doing.

tree type_prime = lang_hooks.types.make_type (RECORD_TYPE);

const char *base_type_name =
  identifier_to_locale ( IDENTIFIER_POINTER ( TYPE_NAME ( type)));
size_t len = strlen ( MY_PREFIX) + strlen ( base_type_name);
char *rec_name = ( char*)alloca ( len + 1);
strcpy ( rec_name, MY_PREFIX);
strcat ( rec_name, base_type_name);

TYPE_NAME ( reorg_type_prime) = get_identifier ( rec_name);

tree field;
tree new_fields = NULL;
for ( field = TYPE_FIELDS ( type); field; field = DECL_CHAIN ( field))
  {
// Probably useful in creating the new field type.
tree old_fld_type = TREE_TYPE ( field);

// Whatever you want the new field type to be
tree new_fld_type = ...;
tree new_decl =
  build_decl ( DECL_SOURCE_LOCATION (field),
  FIELD_DECL, DECL_NAME (field), new_fld_type);
 DECL_CONTEXT ( new_decl) = type_prime;
 layout_decl ( new_decl, 0);
 DECL_CHAIN ( new_decl) = new_fields;
 new_fields = new_decl;
  }

TYPE_FIELDS ( type_prime) = nreverse ( new_fields);
layout_type ( type_prime);

Note, when I change any declaration to have a modified type
I run relayout_decl on them.

If somebody could please tell what bit I'm missing or what I'm doing
wrong I'd really appreciate it. Looking at the code in layout_type,
it should be setting the decl field offsets with place_field and I
don't have a clue what's going on.

Thanks,

Gary


CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for 
the sole use of the intended recipient(s) and contains information that is 
confidential and proprietary to Ampere Computing or its subsidiaries. It is to 
be used solely for the purpose of furthering the parties' business 
relationship. Any unauthorized review, copying, or distribution of this email 
(or any attachments thereto) is strictly prohibited. If you are not the 
intended recipient, please contact the sender immediately and permanently 
delete the original and any copies of this email and any attachments thereto.

Collect2 issue

[Gary Oblock via Gcc]

I'm running my new optimization (LTO with one partition)
on a SPEC17 test.

I got the mysterious message
  "collect2: error: ld returned 1 exit status"

Now, first off, with my debugging on at full tilt and it's
clear my optimization bailed out after analyzing
the code without doing anything.

Second, this is a canned test not modified by
me or anybody else for that matter so, it's
not a user error.

Finally, reading various blogs it seems that
old object files hanging around can make
collect2 to go bonkers. Therefore, I used
specmake to clean the build and it didn't
help, not that this makes any sense with one
partition.

By the way, for those of you that get upset
at the very notion of invoking LTO as one partition,
it's actually not that bad. I can compiler gcc
that way on a laptop in about 50 minuets using
only 4.7% of my memory!

Any ideas?? What's happening, how to diagnose
what's happening, how to work around it, etc...

Thanks,

Gary



CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for 
the sole use of the intended recipient(s) and contains information that is 
confidential and proprietary to Ampere Computing or its subsidiaries. It is to 
be used solely for the purpose of furthering the parties' business 
relationship. Any unauthorized review, copying, or distribution of this email 
(or any attachments thereto) is strictly prohibited. If you are not the 
intended recipient, please contact the sender immediately and permanently 
delete the original and any copies of this email and any attachments thereto.

What version of binutils is required

[Gary Oblock via Gcc]

I'm having a "linker" error (according to Martin Liška) when
compiling a SPEC test (x264_r) with a vendor branch under development  (my 
optimization is done at LTO time.)

The binutils on my development machine is the version
that came with Ubuntu 18.02. Do I need to install a more
current version of binutils?

Thanks,

Gary Oblock


CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for 
the sole use of the intended recipient(s) and contains information that is 
confidential and proprietary to Ampere Computing or its subsidiaries. It is to 
be used solely for the purpose of furthering the parties' business 
relationship. Any unauthorized review, copying, or distribution of this email 
(or any attachments thereto) is strictly prohibited. If you are not the 
intended recipient, please contact the sender immediately and permanently 
delete the original and any copies of this email and any attachments thereto.

Re: What version of binutils is required

[Gary Oblock via Gcc]

Fair enough...

$ ld -V
GNU ld (GNU Binutils for Ubuntu) 2.30


From: Richard Biener 
Sent: Tuesday, February 23, 2021 12:41 AM
To: Gary Oblock 
Cc: gcc@gcc.gnu.org 
Subject: Re: What version of binutils is required

[EXTERNAL EMAIL NOTICE: This email originated from an external sender. Please 
be mindful of safe email handling and proprietary information protection 
practices.]


On Tue, Feb 23, 2021 at 1:12 AM Gary Oblock via Gcc  wrote:
>
> I'm having a "linker" error (according to Martin Liška) when
> compiling a SPEC test (x264_r) with a vendor branch under development  (my 
> optimization is done at LTO time.)
>
> The binutils on my development machine is the version
> that came with Ubuntu 18.02. Do I need to install a more
> current version of binutils?

Just try?  Or at least tell us which version ships with Ubuntu 18.02 ...

> Thanks,
>
> Gary Oblock
>
>
> CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is 
> for the sole use of the intended recipient(s) and contains information that 
> is confidential and proprietary to Ampere Computing or its subsidiaries. It 
> is to be used solely for the purpose of furthering the parties' business 
> relationship. Any unauthorized review, copying, or distribution of this email 
> (or any attachments thereto) is strictly prohibited. If you are not the 
> intended recipient, please contact the sender immediately and permanently 
> delete the original and any copies of this email and any attachments thereto.

What is pex_run

[Gary Oblock via Gcc]

I've got collect2 finding a linker error and I'm out of
other options so I'm poking around in the collect2
sources. I'm wondering what pex_run is (since it's
getting handed the arguments this might mater?)
I figure if I can get collect2 to spill its guts
about what arguments are fed to "ld" I'll have
at least a chance figuring out what in the bleep
is going on... alternate debugging strategies
are welcome.

Thanks,

Gary




CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for 
the sole use of the intended recipient(s) and contains information that is 
confidential and proprietary to Ampere Computing or its subsidiaries. It is to 
be used solely for the purpose of furthering the parties' business 
relationship. Any unauthorized review, copying, or distribution of this email 
(or any attachments thereto) is strictly prohibited. If you are not the 
intended recipient, please contact the sender immediately and permanently 
delete the original and any copies of this email and any attachments thereto.

A weird bug

[Gary Oblock via Gcc]

Guys,

I've been trying to debug a linker error (which I thought was a bug in
my optimization.) Well it turns out it occurs in a brand new virgin
version of the compiler running with binutils 2.36 which is the latest
version. I'm posting this on both the binutils list and gcc list
because people of either list are just as likely to have an idea about
what's going on. Note, I tried to walk though the ld code in gdb but
it's nontrivial trying figure out why an error occured. I can't just
set a watch point on a flag because, at least in some places it seems
like the default state of the flag is failure and the code then
proceeds to try various things to see if they'll work.

Regarding the compiler that I built:

 $ git status
On branch master
Your branch is up to date with 'origin/master'.

nothing to commit, working tree clean

Now here is how I built it:

./my_dual_build_script gcc_virgin_build 2>build_log_virgin 1>&2

where my_dual_build_script is:

cd $1
BASE=`pwd`
echo BASE = $BASE
touch BU_objdir objdir install
rm -rf BU_objdir objdir install
mkdir BU_objdir objdir install

cd BU_objdir
echo BUILDING BINUTILS IN `pwd`
../binutils-2.36/configure --prefix=$BASE/install
make CFLAGS='-O2 -g' CXXFLAGS='-O2 -g' -j 12
##make CFLAGS='-O0 -g' CXXFLAGS='-O2 -g' -j 12
make install

cd ../objdir
echo BUILDING GCC IN `pwd`
../sources/configure --prefix=$BASE/install --disable-bootstrap 
-enable-language=c,c++,lto --disable-multilib --enable-valgrind-annotations
##make CFLAGS='-O0 -g' CXXFLAGS='-O0 -g' -j 12
make CFLAGS='-O2 -g' CXXFLAGS='-O2 -g' -j 12
make install

My installed gcc is:

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 
7.5.0-3ubuntu1~18.04' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs 
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr 
--with-gcc-major-version-only --program-suffix=-7 
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id 
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix 
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu 
--enable-libstdcxx-debug --enable-libstdcxx-time=yes 
--with-default-libstdcxx-abi=new --enable-gnu-unique-object 
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie 
--with-system-zlib --with-target-system-zlib --enable-objc-gc=auto 
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic 
--enable-offload-targets=nvptx-none --without-cuda-driver 
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu 
--target=x86_64-linux-gnu
Thread model: posix
gcc version 7.5.0 (Ubuntu 7.5.0-3ubuntu1~18.04)

My istalled binutils are:

$ ld -v
GNU ld (GNU Binutils for Ubuntu) 2.30

Now the application that failing during testing is 505.x264_5 which is
from SPEC17. Note, please don't try to duplicate this bug unless you
have access to SPEC17 and are running an identical system because
Martin Liska tried to do this on a different system but but he
couldn't get it to duplicate.

Now for any SPEC heads out there here's the germane parts
from its confige file.

   define  gcc_dir/home/gary/gcc_virgin_build/install

   preENV_LD_LIBRARY_PATH  = %{gcc_dir}/lib64/:%{gcc_dir}/lib/:/lib64
   SPECLANG= %{gcc_dir}/bin/
   CC  = $(SPECLANG)gcc --verbose  -std=c99   %{model}
   CXX = $(SPECLANG)g++ -std=c++03 %{model}
   FC  = $(SPECLANG)gfortran   %{model}

   OPTIMIZE   = -O2 -v -Wl,--verbose=1  -Wl,-debug
   COPTIMIZE  = -save-temps

Finally here linker's part of the x264 build output:

/home/gary/gcc_virgin_build/install/lib/gcc/x86_64-pc-linux-gnu/11.0.1/../../../../x86_64-pc-linux-gnu/bin/ld
 -plugin 
/home/gary/gcc_virgin_build/install/libexec/gcc/x86_64-pc-linux-gnu/11.0.1/liblto_plugin.so
 
-plugin-opt=/home/gary/gcc_virgin_build/install/libexec/gcc/x86_64-pc-linux-gnu/11.0.1/lto-wrapper
 -plugin-opt=-fresolution=ldecod_r.res -plugin-opt=-pass-through=-lgcc 
-plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc 
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s 
--eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o 
ldecod_r /usr/lib/x86_64-linux-gnu/crt1.o /usr/lib/x86_64-linux-gnu/crti.o 
/home/gary/gcc_virgin_build/install/lib/gcc/x86_64-pc-linux-gnu/11.0.1/crtbegin.o
 -L/home/gary/gcc_virgin_build/install/lib/gcc/x86_64-pc-linux-gnu/11.0.1 
-L/home/gary/gcc_virgin_build/install/lib/gcc/x86_64-pc-linux-gnu/11.0.1/../../../../lib64
 -L/lib/x86_64-linux-gnu -L/lib/../lib64 -L/usr/lib/x86_64-linux-gnu 
-L/home/gary/gcc_virgin_build/install/lib/gcc/x86_64-pc-linux-gnu/11.0.1/../../../../x86_64-p

Failing in generated file options.c

[Gary Oblock via Gcc]

Guys,

I checked out a fresh copy of the GCC sources today, applied somebodies
patch to it and voila!

options.c:13591:2: error: #error Report option property is dropped #error 
Report option property is dropped

I built this the same minimally convoluted way that I always do.

cd $1
BASE=`pwd`
echo BASE = $BASE
touch objdir install
rm -rf objdir install
mkdir objdir install
cd objdir
echo BUILDING IN `pwd`
../sources/configure --prefix=$BASE/install --disable-bootstrap 
-enable-language=c,c++,lto --disable-multilib --enable-valgrind-annotations
make CFLAGS='-O2 -g' CXXFLAGS='-O2 -g' -j 12
make install

The file option.c is generated in objdir/gcc by an awk script:

mawk -f ../../sources/gcc/opt-functions.awk -f ../../sources/gcc/opt-read.awk \
   -f ../../sources/gcc/optc-gen.awk \
   -v header_name="config.h system.h coretypes.h options.h tm.h" < 
optionlist > options.c

Does anyone  have any idea what's going to here?


CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for 
the sole use of the intended recipient(s) and contains information that is 
confidential and proprietary to Ampere Computing or its subsidiaries. It is to 
be used solely for the purpose of furthering the parties' business 
relationship. Any unauthorized review, copying, or distribution of this email 
(or any attachments thereto) is strictly prohibited. If you are not the 
intended recipient, please contact the sender immediately and permanently 
delete the original and any copies of this email and any attachments thereto.

Some really strange GIMPLE

[Gary Oblock via Gcc]

I'm chasing a bug and I used Creduce to produce a
reduced test case. However, that's really beside to
point.

I this file:

typedef struct basket {
} a;
long b;
a *basket;
int d, c, e;
a *flake[2];
void primal_bea_mpp();
void primal_net_simplex() {
  flake[1] = &basket[1];
  primal_bea_mpp(d, d, d, b, flake, 0, e, c, c, d);
}

Produces this GIMPLE:
-
;; Function primal_net_simplex (primal_net_simplex, funcdef_no=3, 
decl_uid=4447, cgraph_uid=16, symbol_order=41) (executed once)

primal_net_simplex ()
{
   [local count: 1073741824]:
  _1 = basket;
  static struct a * flake[2];
struct a *[2]
  flake[1] = _1;
  _2 = d;
  _3 = c;
  _4 = e;
  _5 = b;
  primal_bea_mpp (_2, _2, _2, _5, &flake, 0, _4, _3, _3, _2);
  return;

}
--
These standard calls were used to dump this:

  FOR_EACH_FUNCTION_WITH_GIMPLE_BODY ( node)
  {
struct function *func = DECL_STRUCT_FUNCTION ( node->decl);
dump_function_header ( file, func->decl, (dump_flags_t)0);
dump_function_to_file ( func->decl, file, (dump_flags_t)0);
  }

The GIMPLE above looks malformed to me. Is that the case
or am I not grasping what's going on here?

Note, I wouldn't be asking this question if this wasn't at the start of
my pass and looking at stuff I hadn't modified.

Thanks,

Gary


CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for 
the sole use of the intended recipient(s) and contains information that is 
confidential and proprietary to Ampere Computing or its subsidiaries. It is to 
be used solely for the purpose of furthering the parties' business 
relationship. Any unauthorized review, copying, or distribution of this email 
(or any attachments thereto) is strictly prohibited. If you are not the 
intended recipient, please contact the sender immediately and permanently 
delete the original and any copies of this email and any attachments thereto.

What is going on here with fixup_cfg?

[Gary Oblock via Gcc]

My jaws hit the floor when I saw this bug:

psimplex.c: In function ‘master.constprop’:
psimplex.c:124:6: error: non-trivial conversion in ‘constructor’
  124 | void master(network_t *net, int num_threads)
  |  ^
struct _modif_basket *[4061]
struct _modif_basket *[4061]
struct _modif_basket *[4061]
struct _modif_basket *[4061]
# .MEM_111 = VDEF <.MEM_103>
perm ={v} {CLOBBER};
during GIMPLE pass: fixup_cfg
psimplex.c:124:6: internal compiler error: verify_gimple failed
0x12da3a4 verify_gimple_in_cfg(function*, bool)
../../sources/gcc/tree-cfg.c:5482
0x10e69f8 execute_function_todo
../../sources/gcc/passes.c:1992
0x10e598b do_per_function
../../sources/gcc/passes.c:1640
0x10e6be8 execute_todo
../../sources/gcc/passes.c:2046

I've included a bit too much stuff but the bit that
confused the heck out of me was the

struct _modif_basket *[4061]
struct _modif_basket *[4061]

associated with the clobber.

I've been banging away for few days
trying to make the types associated with
the left and right hand sides of this clobber
agree and now it's complaining about that
too?!

The type of perm has changed so what
should right hand type be now? When
dumping out other instances of clobber,
the instances all matched so why should
this need to be different?

Thanks,

Gary


CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for 
the sole use of the intended recipient(s) and contains information that is 
confidential and proprietary to Ampere Computing or its subsidiaries. It is to 
be used solely for the purpose of furthering the parties' business 
relationship. Any unauthorized review, copying, or distribution of this email 
(or any attachments thereto) is strictly prohibited. If you are not the 
intended recipient, please contact the sender immediately and permanently 
delete the original and any copies of this email and any attachments thereto.

Re: Gcc Digest, Vol 15, Issue 5

[Gary Oblock via Gcc]

I've got to say appearances can be deceptive
in GCC and struct _modif_basket *[4061] is not
necessarily equal to struct _modif_basket *[4061]
even though the printed representation is
the same...

Gary

From: Gcc  on behalf of gcc-requ...@gcc.gnu.org 

Sent: Tuesday, May 4, 2021 1:48 PM
To: gcc@gcc.gnu.org 
Subject: Gcc Digest, Vol 15, Issue 5

[EXTERNAL EMAIL NOTICE: This email originated from an external sender. Please 
be mindful of safe email handling and proprietary information protection 
practices.]


Send Gcc mailing list submissions to
gcc@gcc.gnu.org

To subscribe or unsubscribe via the World Wide Web, visit
https://gcc.gnu.org/mailman/listinfo/gcc
or, via email, send a message with subject or body 'help' to
gcc-requ...@gcc.gnu.org

You can reach the person managing the list at
gcc-ow...@gcc.gnu.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Gcc digest..."

A simple debugging question

[Gary Oblock via Gcc]

OK, I haven't asked a dumb question for a while so here goes!

I'm trying to debug my optimization in lto running 505mcf_r
(yes it's SPEC17.)

Here's the bit that fails from the make.out:

/home/gary/gcc_build_gcc11/install/libexec/gcc/x86_64-pc-linux-gnu/11.1.1/lto1 
-quiet -dumpdir ./mcf_r.lto.o- -dumpbase mcf_r.lto.o -dumpbase-ext .o -m64 
-mtune=generic -march=x86-64 -O3 -O3 -Wdfa -version -fno-openmp -fno-openacc 
-fno-pie -fcf-protection=none -fcommon -fdump-ipa-type-escape-analysis 
-fdump-ipa-field-reorder -funroll-loops -flto-partition=none 
-fipa-instance-interleave -fdump-ipa-all-details -fno-ipa-icf 
-fipa-type-escape-analysis -fipa-field-reorder -fresolution=mcf_r.res 
-flinker-output=exec --param=early-inlining-insns=96 
--param=max-inline-insns-auto=64 --param=inline-unit-growth=96 
@./mcf_r.lto.o-args.0 -o ./mcf_r.lto.o-mcf_r.lto.s

I bring up emacs and go into gdb.

I set it to debug the lto1 path above.

I cd to the build area:
cd 
gary@SCC-PC0TYGP5:~/spec/cpu2017/benchspec/CPU/525.x264_r/build/build_base_gcc11_rate_ampere-64.

I set my beakpoint:
break tree-ssa-sccvn.c:5975

I give the breakpoint a condition (yes I instrumented the code just to do this):
cond 1 (count == 5326)

Finally, I run lto1 with the long list of arguments above.

It runs a tiny bit and gives me:
lto1: fatal error: could not open symbol resolution file: No such file or 
directory

This is a new one for me guys and I've used this approach above
many times (but not on a SPEC build.) Any hints at what I did
wrong?

Note, during development I always build gcc with "-O0 -g".

Thanks,

Gary


CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for 
the sole use of the intended recipient(s) and contains information that is 
confidential and proprietary to Ampere Computing or its subsidiaries. It is to 
be used solely for the purpose of furthering the parties' business 
relationship. Any unauthorized review, copying, or distribution of this email 
(or any attachments thereto) is strictly prohibited. If you are not the 
intended recipient, please contact the sender immediately and permanently 
delete the original and any copies of this email and any attachments thereto.

Re: A simple debugging question

[Gary Oblock via Gcc]

Richard,

Opps! I see my problem. I changed directory into
x264 and not mcf!

I need to stop working so late

Thank you for your input because led me to question
my assumptions about what was going on.

Gary


From: Richard Biener 
Sent: Wednesday, July 14, 2021 12:23 AM
To: Gary Oblock 
Cc: gcc@gcc.gnu.org 
Subject: Re: A simple debugging question

[EXTERNAL EMAIL NOTICE: This email originated from an external sender. Please 
be mindful of safe email handling and proprietary information protection 
practices.]


On Wed, Jul 14, 2021 at 6:42 AM Gary Oblock via Gcc  wrote:
>
> OK, I haven't asked a dumb question for a while so here goes!
>
> I'm trying to debug my optimization in lto running 505mcf_r
> (yes it's SPEC17.)
>
> Here's the bit that fails from the make.out:
>
> /home/gary/gcc_build_gcc11/install/libexec/gcc/x86_64-pc-linux-gnu/11.1.1/lto1
>  -quiet -dumpdir ./mcf_r.lto.o- -dumpbase mcf_r.lto.o -dumpbase-ext .o -m64 
> -mtune=generic -march=x86-64 -O3 -O3 -Wdfa -version -fno-openmp -fno-openacc 
> -fno-pie -fcf-protection=none -fcommon -fdump-ipa-type-escape-analysis 
> -fdump-ipa-field-reorder -funroll-loops -flto-partition=none 
> -fipa-instance-interleave -fdump-ipa-all-details -fno-ipa-icf 
> -fipa-type-escape-analysis -fipa-field-reorder -fresolution=mcf_r.res 
> -flinker-output=exec --param=early-inlining-insns=96 
> --param=max-inline-insns-auto=64 --param=inline-unit-growth=96 
> @./mcf_r.lto.o-args.0 -o ./mcf_r.lto.o-mcf_r.lto.s
>
> I bring up emacs and go into gdb.
>
> I set it to debug the lto1 path above.
>
> I cd to the build area:
> cd 
> gary@SCC-PC0TYGP5:~/spec/cpu2017/benchspec/CPU/525.x264_r/build/build_base_gcc11_rate_ampere-64.
>
> I set my beakpoint:
> break tree-ssa-sccvn.c:5975
>
> I give the breakpoint a condition (yes I instrumented the code just to do 
> this):
> cond 1 (count == 5326)
>
> Finally, I run lto1 with the long list of arguments above.
>
> It runs a tiny bit and gives me:
> lto1: fatal error: could not open symbol resolution file: No such file or 
> directory
>
> This is a new one for me guys and I've used this approach above
> many times (but not on a SPEC build.) Any hints at what I did
> wrong?

You have to preserve temporary files (the symbol resolution file) with
-save-temps and if you did
the lto1 invocation will have to happen from the directory that file resides in
(-fresolution=mcf_r.res), otherwise lto1 won't find it.

> Note, during development I always build gcc with "-O0 -g".
>
> Thanks,
>
> Gary
>
>
> CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is 
> for the sole use of the intended recipient(s) and contains information that 
> is confidential and proprietary to Ampere Computing or its subsidiaries. It 
> is to be used solely for the purpose of furthering the parties' business 
> relationship. Any unauthorized review, copying, or distribution of this email 
> (or any attachments thereto) is strictly prohibited. If you are not the 
> intended recipient, please contact the sender immediately and permanently 
> delete the original and any copies of this email and any attachments thereto.

A value number issue

[Gary Oblock via Gcc]

I seem to be having a problem with the pre pass.

When eliminate_dom_walker::eliminate_stmt is called with
the gsi to "dedangled_864 = bea_43->tail;" which in turn
calls eliminate_dom_walker::eliminate_avail op of dedangled_864.
This gives VN_INFO (lhs)->valnum of _920. The _920 is not
associated with any SSA variable in the function and I don't
see how it got associated with dedangled_864. This is not
a theoretical issue because it causes an error (the gcc_unreachable
in eliminate_stmt is called.)

Here is how _920 (in function main) is used.

  _920 = arcnew_916->head;
  _921 = MEM[(struct node.reorg.reorder *)_920].firstin;
  MEM[(struct node.reorg.reorder *)_920].firstin = arcnew_916;

Here is how dedangled_864 is used:

   [local count: 2609125]:
  dedangled_863 = bea_43->head;
  dedangled_864 = bea_43->tail;
  goto ; [100.00%]

   [local count: 1813121]:
  dedangled_865 = bea_43->tail;
  dedangled_866 = bea_43->head;

   [local count: 4422246]:
  # dedangled_867 = PHI 
  # dedangled_868 = PHI 
  delta_461 = 1;
  goto ; [100.00%]

Note, dedangled_868 is used in an ever widening net of
phis and operations. Also, the other similar statements

  dedangled_863 = bea_43->head;
  dedangled_865 = bea_43->tail;
  dedangled_866 = bea_43->head;

don't seem to be malformed.

I tried using a watchpoint to see what was happening but that turned
out to be not productive in that it was tripping on something
unrelated even if I set it at the start of the pre pass.

I'm assuming that some of my code is malformed in some
subtle way and I was wondering it anybody had any ideas?
I say subtle because this was all working on a slightly different
version of gcc without the code of some other Ampere optimizations
in the mix (I disabled those optimizations and things still failed.)

Note, if you guys don't have any ideas the next approach is adding
tons of brute force instrumentation and special purpose sanity
checking to the value numbering routine... please help me avoid that.

Thanks,

Gary


CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for 
the sole use of the intended recipient(s) and contains information that is 
confidential and proprietary to Ampere Computing or its subsidiaries. It is to 
be used solely for the purpose of furthering the parties' business 
relationship. Any unauthorized review, copying, or distribution of this email 
(or any attachments thereto) is strictly prohibited. If you are not the 
intended recipient, please contact the sender immediately and permanently 
delete the original and any copies of this email and any attachments thereto.

Re: A value number issue

[Gary Oblock via Gcc]

_arry_addr_591,-8} 
(0924), {pointer_plus_expr,field_arry_addr_601,-8} (0926) }
:
Replaced bea_43->tail with _975 in dedangled_864 = bea_43->tail;
:
  long int pretmp_859;
  struct node * * field_addr_860;
  struct node * field_val_temp_861;
  unsigned long dedangled_863;
  unsigned long dedangled_864;
  unsigned long dedangled_865;
  unsigned long dedangled_866;
  :
 [local count: 4422246]:
  _58 = MEM[(int64_t *)&net + 608B];
  _59 = _58 + 1;
  MEM[(int64_t *)&net + 608B] = _59;
  dedangled_865 = bea_43->tail;
  dedangled_863 = bea_43->head;
  _975 = (struct node.reorg.reorder *) dedangled_865;
  dedangled_864 = bea_43->tail;
  dedangled_866 = bea_43->head;
  if (red_cost_of_bea_42 > 0)
goto ; [59.00%]
  else
goto ; [41.00%]

   [local count: 2609125]:
  goto ; [100.00%]

   [local count: 1813121]:

   [local count: 4422246]:
  # dedangled_867 = PHI 
  # dedangled_868 = PHI 
  if (dedangled_867 != dedangled_868)
goto ; [89.00%]
  else
goto ; [11.00%]
=
I was pretty arbitrary here about what I extracted from the
dump file but it's 33MB in size.

I'm still thinking it's something dumb that I did
when I created "dedangled_864" but I can't spot it from
the dump. Does anyone have any ideas? Note, before I
looked at the dump I at least had a half-baked idea
of what to try but now this leaves me without a clue
as to what to do (I'm going to read up on the original
algorithm.)

Thanks,

Gary


From: Richard Biener 
Sent: Thursday, July 22, 2021 5:18 AM
To: Gary Oblock 
Cc: gcc@gcc.gnu.org 
Subject: Re: A value number issue

[EXTERNAL EMAIL NOTICE: This email originated from an external sender. Please 
be mindful of safe email handling and proprietary information protection 
practices.]


On Thu, Jul 22, 2021 at 8:06 AM Gary Oblock via Gcc  wrote:
>
> I seem to be having a problem with the pre pass.
>
> When eliminate_dom_walker::eliminate_stmt is called with
> the gsi to "dedangled_864 = bea_43->tail;" which in turn
> calls eliminate_dom_walker::eliminate_avail op of dedangled_864.
> This gives VN_INFO (lhs)->valnum of _920. The _920 is not
> associated with any SSA variable in the function and I don't
> see how it got associated with dedangled_864. This is not
> a theoretical issue because it causes an error (the gcc_unreachable
> in eliminate_stmt is called.)

But you show below the definition of _920 so I don't quite understand
your question.  You can follow VNs reasoning in the -details dump.

>
> Here is how _920 (in function main) is used.
>
>   _920 = arcnew_916->head;
>   _921 = MEM[(struct node.reorg.reorder *)_920].firstin;
>   MEM[(struct node.reorg.reorder *)_920].firstin = arcnew_916;
>
> Here is how dedangled_864 is used:
>
>[local count: 2609125]:
>   dedangled_863 = bea_43->head;
>   dedangled_864 = bea_43->tail;
>   goto ; [100.00%]
>
>[local count: 1813121]:
>   dedangled_865 = bea_43->tail;
>   dedangled_866 = bea_43->head;
>
>[local count: 4422246]:
>   # dedangled_867 = PHI 
>   # dedangled_868 = PHI 
>   delta_461 = 1;
>   goto ; [100.00%]
>
> Note, dedangled_868 is used in an ever widening net of
> phis and operations. Also, the other similar statements
>
>   dedangled_863 = bea_43->head;
>   dedangled_865 = bea_43->tail;
>   dedangled_866 = bea_43->head;
>
> don't seem to be malformed.
>
> I tried using a watchpoint to see what was happening but that turned
> out to be not productive in that it was tripping on something
> unrelated even if I set it at the start of the pre pass.
>
> I'm assuming that some of my code is malformed in some
> subtle way and I was wondering it anybody had any ideas?
> I say subtle because this was all working on a slightly different
> version of gcc without the code of some other Ampere optimizations
> in the mix (I disabled those optimizations and things still failed.)
>
> Note, if you guys don't have any ideas the next approach is adding
> tons of brute force instrumentation and special purpose sanity
> checking to the value numbering routine... please help me avoid that.
>
> Thanks,
>
> Gary
>
>
> CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is 
> for the sole use of the intended recipient(s) and contains information that 
> is confidential and proprietary to Ampere Computing or its subsidiaries. It 
> is to be used solely for the purpose of furthering the parties' business 
> relationship. Any unauthorized review, copying, or distribution of this email 
> (or any attachments thereto) is strictly prohibited. If you are not the 
> intended recipient, please contact the sender immediately and permanently 
> delete the original and any copies of this email and any attachments thereto.

Re: A value number issue

[Gary Oblock via Gcc]

_expr,red_cost_of_bea_42} (0134), 
> {component_ref,mem_ref<0B>,addr_expr<&_reorg_base_var_node.reorg.reorder>}@.MEM_387
>  (0306), 
> {component_ref,mem_ref<0B>,addr_expr<&_reorg_base_var_node.reorg.reorder>}@.MEM_387
>  (0312), 
> {component_ref,mem_ref<0B>,addr_expr<&_reorg_base_var_node.reorg.reorder>}@.MEM_387
>  (0327), 
> {component_ref,mem_ref<0B>,addr_expr<&_reorg_base_var_node.reorg.reorder>}@.MEM_387
>  (0339), {pointer_plus_expr,field_arry_addr_581,-8} (0921), 
> {bit_xor_expr,xchange_900,1} (0923), 
> {pointer_plus_expr,field_arry_addr_591,-8} (0924), 
> {pointer_plus_expr,field_arry_addr_601,-8} (0926) }
> :
> Replaced bea_43->tail with _975 in dedangled_864 = bea_43->tail;
> :
>   long int pretmp_859;
>   struct node * * field_addr_860;
>   struct node * field_val_temp_861;
>   unsigned long dedangled_863;
>   unsigned long dedangled_864;
>   unsigned long dedangled_865;
>   unsigned long dedangled_866;
>   :
>  [local count: 4422246]:
>   _58 = MEM[(int64_t *)&net + 608B];
>   _59 = _58 + 1;
>   MEM[(int64_t *)&net + 608B] = _59;
>   dedangled_865 = bea_43->tail;
>   dedangled_863 = bea_43->head;
>   _975 = (struct node.reorg.reorder *) dedangled_865;
>   dedangled_864 = bea_43->tail;
>   dedangled_866 = bea_43->head;
>   if (red_cost_of_bea_42 > 0)
> goto ; [59.00%]
>   else
> goto ; [41.00%]
>
>[local count: 2609125]:
>   goto ; [100.00%]
>
>[local count: 1813121]:
>
>[local count: 4422246]:
>   # dedangled_867 = PHI 
>   # dedangled_868 = PHI 
>   if (dedangled_867 != dedangled_868)
> goto ; [89.00%]
>   else
> goto ; [11.00%]
> =
> I was pretty arbitrary here about what I extracted from the
> dump file but it's 33MB in size.
>
> I'm still thinking it's something dumb that I did
> when I created "dedangled_864" but I can't spot it from
> the dump. Does anyone have any ideas? Note, before I
> looked at the dump I at least had a half-baked idea
> of what to try but now this leaves me without a clue
> as to what to do (I'm going to read up on the original
> algorithm.)
>
> Thanks,
>
> Gary
>
> 
> From: Richard Biener 
> Sent: Thursday, July 22, 2021 5:18 AM
> To: Gary Oblock 
> Cc: gcc@gcc.gnu.org 
> Subject: Re: A value number issue
>
> [EXTERNAL EMAIL NOTICE: This email originated from an external sender. Please 
> be mindful of safe email handling and proprietary information protection 
> practices.]
>
>
> On Thu, Jul 22, 2021 at 8:06 AM Gary Oblock via Gcc  wrote:
> >
> > I seem to be having a problem with the pre pass.
> >
> > When eliminate_dom_walker::eliminate_stmt is called with
> > the gsi to "dedangled_864 = bea_43->tail;" which in turn
> > calls eliminate_dom_walker::eliminate_avail op of dedangled_864.
> > This gives VN_INFO (lhs)->valnum of _920. The _920 is not
> > associated with any SSA variable in the function and I don't
> > see how it got associated with dedangled_864. This is not
> > a theoretical issue because it causes an error (the gcc_unreachable
> > in eliminate_stmt is called.)
>
> But you show below the definition of _920 so I don't quite understand
> your question.  You can follow VNs reasoning in the -details dump.
>
> >
> > Here is how _920 (in function main) is used.
> >
> >   _920 = arcnew_916->head;
> >   _921 = MEM[(struct node.reorg.reorder *)_920].firstin;
> >   MEM[(struct node.reorg.reorder *)_920].firstin = arcnew_916;
> >
> > Here is how dedangled_864 is used:
> >
> >[local count: 2609125]:
> >   dedangled_863 = bea_43->head;
> >   dedangled_864 = bea_43->tail;
> >   goto ; [100.00%]
> >
> >[local count: 1813121]:
> >   dedangled_865 = bea_43->tail;
> >   dedangled_866 = bea_43->head;
> >
> >[local count: 4422246]:
> >   # dedangled_867 = PHI 
> >   # dedangled_868 = PHI 
> >   delta_461 = 1;
> >   goto ; [100.00%]
> >
> > Note, dedangled_868 is used in an ever widening net of
> > phis and operations. Also, the other similar statements
> >
> >   dedangled_863 = bea_43->head;
> >   dedangled_865 = bea_43->tail;
> >   dedangled_866 = bea_43->head;
> >
> > don't seem to be malformed.
> >
> > I tried using a watchpoint to see what was happening but that turned
> > out to be not productive in that it was tripping on something
> > unrelated even if I set it at the start of the pre pass.
> >
> > I'm assuming that some of my code is malformed in some
> > subtle way and I was wondering it anybody had any ideas?
> > I say subtle because this was all working on a slightly different
> > version of gcc without the code of some other Ampere optimizations
> > in the mix (I disabled those optimizations and things still failed.)
> >
> > Note, if you guys don't have any ideas the next approach is adding
> > tons of brute force instrumentation and special purpose sanity
> > checking to the value numbering routine... please help me avoid that.
> >
> > Thanks,
> >
> > Gary
> >
> >
> > CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is 
> > for the sole use of the intended recipient(s) and contains information that 
> > is confidential and proprietary to Ampere Computing or its subsidiaries. It 
> > is to be used solely for the purpose of furthering the parties' business 
> > relationship. Any unauthorized review, copying, or distribution of this 
> > email (or any attachments thereto) is strictly prohibited. If you are not 
> > the intended recipient, please contact the sender immediately and 
> > permanently delete the original and any copies of this email and any 
> > attachments thereto.

Re: A value number issue

[Gary Oblock via Gcc]

t; > phi_gen[37] := {  }
> > tmp_gen[37] := {  }
> > avail_out[37] := { xchange_449(D) (0232), arcs_1 (0003), stop_arcs_2 
> > (0004), _4 (0006), _5 (0007), i_646 (0340), _7 (0008), _8 (0009), _9 
> > (0010), i_10 (0011), _212 (0112), xchange_900 (0431), end_arc_385 (0180), 
> > _14 (0013), _19 (0015), field_arry_addr_112 (0045), i_665 (0352), next_666 
> > (0353), _163 (0081), next_218 (0113), _173 (0083), _178 (0086), _179 
> > (0087), _176 (0084), end_arc_443 (0226), end_arc_444 (0227), end_arc_445 
> > (0228), _222 (0238), _223 (0115), _224 (0116), _225 (0117), _226 (0118), 
> > _227 (0119), _228 (0120), _229 (0121), _231 (0123), _21 (0016), 
> > red_cost_of_bea_42 (0019), bea_43 (0020), i_649 (0343), _45 (0021), _46 
> > (0022), _47 (0023), _58 (0027), _59 (0028), dedangled_865 (0408), 
> > dedangled_863 (0407), dedangled_864 (0448), dedangled_866 (0229) }
> > exp_gen[38] := { dedangled_867 (0409), dedangled_868 (0410) }
> > phi_gen[38] := { dedangled_867 (0409), dedangled_868 (0410) }
> > tmp_gen[38] := {  }
> > avail_out[38] := { xchange_449(D) (0232), arcs_1 (0003), stop_arcs_2 
> > (0004), _4 (0006), _5 (0007), i_646 (0340), _7 (0008), _8 (0009), _9 
> > (0010), i_10 (0011), _212 (0112), xchange_900 (0431), end_arc_385 (0180), 
> > _14 (0013), _19 (0015), field_arry_addr_112 (0045), i_665 (0352), next_666 
> > (0353), _163 (0081), next_218 (0113), _173 (0083), _178 (0086), _179 
> > (0087), _176 (0084), end_arc_443 (0226), end_arc_444 (0227), end_arc_445 
> > (0228), _222 (0238), _223 (0115), _224 (0116), _225 (0117), _226 (0118), 
> > _227 (0119), _228 (0120), _229 (0121), _231 (0123), _21 (0016), 
> > red_cost_of_bea_42 (0019), bea_43 (0020), i_649 (0343), _45 (0021), _46 
> > (0022), _47 (0023), _58 (0027), _59 (0028), dedangled_865 (0408), 
> > dedangled_863 (0407), dedangled_864 (0448), dedangled_866 (0229), 
> > dedangled_867 (0409), dedangled_868 (0410) }
> > (a presence in the avail_out for rest until it reaches a point where is in 
> > none of them)
> > :
> > ANTIC_OUT[166] := { {mem_ref<0B>,addr_expr<&opt>}@.MEM_104(D) (0112), 
> > bea_43 (0020), dedangled_863 (0407), dedangled_864 (0448) }
> > [changed] ANTIC_IN[166] := { {mem_ref<0B>,addr_expr<&opt>}@.MEM_104(D) 
> > (0112), bea_43 (0020), dedangled_863 (0407), dedangled_864 (0448) }
> > S[166] := { {mem_ref<0B>,addr_expr<&opt>}@.MEM_104(D) (0112), bea_43 
> > (0020), dedangled_863 (0407), dedangled_864 (0448) }
> > :
> > PA_OUT[36] := { stop_arcs_2 (0004), _4 (0006), 
> > {mem_ref<0B>,addr_expr<&opt>}@.MEM_104(D) (0112), xchange_900 (0431), 
> > {mem_ref<0B>,addr_expr<&opt_basket>}@.MEM_104(D) (0015), 
> > {mem_ref<0B>,addr_expr<&full_group_end_arc>}@.MEM_104(D) (0083), 
> > end_arc_445 (0228), {mem_ref<0B>,addr_expr<&perm_p>}@.MEM_104(D) (0016), 
> > red_cost_of_bea_42 (0019), bea_43 (0020), dedangled_865 (0408), 
> > dedangled_863 (0407), dedangled_864 (0448), dedangled_866 (0229), 
> > {mem_ref<616B>,addr_expr<&net>}@.MEM_99 (0442), {plus_expr,_913,1} (0438), 
> > {component_ref,mem_ref<0B>,addr_expr<&_reorg_base_var_node.reorg.reorder>}@.MEM_387
> >  (0258), 
> > {component_ref,mem_ref<0B>,addr_expr<&_reorg_base_var_node.reorg.reorder>}@.MEM_387
> >  (0274), 
> > {component_ref,mem_ref<0B>,addr_expr<&_reorg_base_var_node.reorg.reorder>}@.MEM_387
> >  (0265), 
> > {component_ref,mem_ref<0B>,addr_expr<&_reorg_base_var_node.reorg.reorder>}@.MEM_387
> >  (0049), 
> > {component_ref,mem_ref<0B>,addr_expr<&_reorg_base_var_node.reorg.reorder>}@.MEM_387
> >  (0299), {component_ref,mem_ref<0B>,addr_expr<&net>}@.MEM_387 
> > (0222), {abs_expr,red_cost_of_bea_42} (0134), 
> > {component_ref,mem_ref<0B>,addr_expr<&_reorg_base_var_node.reorg.reorder>}@.MEM_387
> >  (0306), 
> > {component_ref,mem_ref<0B>,addr_expr<&_reorg_base_var_node.reorg.reorder>}@.MEM_387
> >  (0312), 
> > {component_ref,mem_ref<0B>,addr_expr<&_reorg_base_var_node.reorg.reorder>}@.MEM_387
> >  (0327), 
> > {component_ref,mem_ref<0B>,addr_expr<&_reorg_base_var_node.reorg.reorder>}@.MEM_387
> >  (0339), {pointer_plus_expr,field_arry_addr_581,-8} (0921), 
> > {bit_xor_expr,xchange_900,1} (0923), 
> > {pointer_plus_expr,field_arry_addr_591,-8} (0924), 
> > {pointer_plus_expr,field_arry_addr_601,-8} (0926) }
> > :
> > Replaced bea_43->tail with _975 in dedangled_864 = bea_43->tail;
> > :

What is this GIMPLE?

[Gary Oblock via Gcc]

I print out a bit of GIMPLE for a program and it looks like this:

   [local count: 13634385]:
  # a_1 = PHI 
  # n_11 = PHI 
loop:
  # DEBUG n => n_11
  # DEBUG a => a_1
  _2 = (long unsigned int) a_1;
  _3 = _2 & 7;
  _347 = _3 != 0;

That bit that says "loop:" isn't a GIMPLE_LABEL and
it has operands, the first of which is "size_t n = size_t;"
and I find that a bit odd...

What is this thing and what does it do? Note, I'm trying to
parse and transform some GIMPLE and this is confusing my
code (and me.) I looked in the internals doc and grepped the
code but I'm still in the dark.

Note,I'd like be able to detect and ignore this if it's just informational.

Thanks,

Gary

Gary


CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for 
the sole use of the intended recipient(s) and contains information that is 
confidential and proprietary to Ampere Computing or its subsidiaries. It is to 
be used solely for the purpose of furthering the parties' business 
relationship. Any unauthorized review, copying, or distribution of this email 
(or any attachments thereto) is strictly prohibited. If you are not the 
intended recipient, please contact the sender immediately and permanently 
delete the original and any copies of this email and any attachments thereto.

Re: What is this GIMPLE?

[Gary Oblock via Gcc]

Richard,

It sure looked a label but I had code that would bail out on
a label before it ever got where I was seeing a problem.

I finally printed out the gimple code and it was a GIMPLE_DEBUG!
When I bailed out on debugs my pass worked again. Of course
expanding debugging info failed in cfgexpand. It looks like "-g"
and my stuff real don't play nice together. Any thoughts on
what to do? I'm thing about simply disabling my stuff if "-g"
is specified. This is not the macho thing to do but anything is likely
a very deep rathole.

Thanks,

Gary



From: Richard Biener 
Sent: Thursday, August 26, 2021 12:45 AM
To: Gary Oblock 
Cc: gcc@gcc.gnu.org 
Subject: Re: What is this GIMPLE?

[EXTERNAL EMAIL NOTICE: This email originated from an external sender. Please 
be mindful of safe email handling and proprietary information protection 
practices.]


On Wed, Aug 25, 2021 at 7:30 AM Gary Oblock via Gcc  wrote:
>
> I print out a bit of GIMPLE for a program and it looks like this:
>
>[local count: 13634385]:
>   # a_1 = PHI 
>   # n_11 = PHI 
> loop:
>   # DEBUG n => n_11
>   # DEBUG a => a_1
>   _2 = (long unsigned int) a_1;
>   _3 = _2 & 7;
>   _347 = _3 != 0;
>
> That bit that says "loop:" isn't a GIMPLE_LABEL and
> it has operands, the first of which is "size_t n = size_t;"
> and I find that a bit odd...

I'm sure it is a GIMPLE_LABEL.

> What is this thing and what does it do? Note, I'm trying to
> parse and transform some GIMPLE and this is confusing my
> code (and me.) I looked in the internals doc and grepped the
> code but I'm still in the dark.
>
> Note,I'd like be able to detect and ignore this if it's just informational.
>
> Thanks,
>
> Gary
>
> Gary
>
>
> CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is 
> for the sole use of the intended recipient(s) and contains information that 
> is confidential and proprietary to Ampere Computing or its subsidiaries. It 
> is to be used solely for the purpose of furthering the parties' business 
> relationship. Any unauthorized review, copying, or distribution of this email 
> (or any attachments thereto) is strictly prohibited. If you are not the 
> intended recipient, please contact the sender immediately and permanently 
> delete the original and any copies of this email and any attachments thereto.

Build gcc question

[Gary Oblock via Gcc]

I've got a really amazingly bizarre bug, when running my modified
gcc under gdb, I see some bewildering behavior. So, before I start
debugging at the assembly level, I'd like to see some .s files.
This led me to try adding "-save-temps" to the CFLAGS and
CXXFLAGS on the make command line. This in turn led to plethora
of different assembly errors. Is this supposed to happen
and is there another way to preserve .s files?

Thanks,

Gary


CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for 
the sole use of the intended recipient(s) and contains information that is 
confidential and proprietary to Ampere Computing or its subsidiaries. It is to 
be used solely for the purpose of furthering the parties' business 
relationship. Any unauthorized review, copying, or distribution of this email 
(or any attachments thereto) is strictly prohibited. If you are not the 
intended recipient, please contact the sender immediately and permanently 
delete the original and any copies of this email and any attachments thereto.

Can gcc itself be tested with ubsan? If so, how?

[Gary Oblock via Gcc]

I tried just adding "-fsanitize=undefined" to my CXX_FLAGS and got
a bunch of errors like this:

/usr/bin/ld: ../libcody/libcody.a(server.o): in function 
`std::__cxx11::basic_string, std::allocator 
>::_Alloc_hider::~_Alloc_hider()':
/usr/include/c++/9/bits/basic_string.h:150: undefined reference to 
`__ubsan_handle_type_mismatch_v1'

They all seemed library related.

Can ubsan be used on the compiler itself?

Thanks,

Gary




CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for 
the sole use of the intended recipient(s) and contains information that is 
confidential and proprietary to Ampere Computing or its subsidiaries. It is to 
be used solely for the purpose of furthering the parties' business 
relationship. Any unauthorized review, copying, or distribution of this email 
(or any attachments thereto) is strictly prohibited. If you are not the 
intended recipient, please contact the sender immediately and permanently 
delete the original and any copies of this email and any attachments thereto.

Re: Can gcc itself be tested with ubsan? If so, how?

[Gary Oblock via Gcc]

Toon,

I assume the final compiler built this way has ubsan? I ask because
I'm trying to spot a bug in a new optimization so I want to
run it on a specific test case with the new optimization
enabled.

Thanks,

Gary


From: Toon Moene 
Sent: Monday, September 27, 2021 11:47 PM
To: Erick Ochoa ; Gary Oblock 
Cc: gcc@gcc.gnu.org 
Subject: Re: Can gcc itself be tested with ubsan? If so, how?

[EXTERNAL EMAIL NOTICE: This email originated from an external sender. Please 
be mindful of safe email handling and proprietary information protection 
practices.]


On 9/28/21 8:35 AM, Erick Ochoa via Gcc wrote:

>> Can ubsan be used on the compiler itself?

I regularly build the compiler(s) natively with ubsan enabled, see for
instance:

https://gcc.gnu.org/pipermail/gcc-testresults/2021-September/719448.html

The configure line tells you how to do it (towards the end of the mail):

configure flags: --prefix=/home/toon/compilers/install/gcc --with-gnu-as
--with-gnu-ld --enable-languages=all,ada --disable-multilib
--disable-nls --with-build-config=bootstrap-ubsan --enable-checking=all

(the enable-checking part is not relevant, and can be omitted).

Kind regards,

--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands

Re: Can gcc itself be tested with ubsan? If so, how?

[Gary Oblock via Gcc]

I suppose I should answer my own question

Yes, the final compiler built has ubsan enabled.

Gary

PS. The faint hearted should note this is an overnight build. It would be nice 
if this wasn't tied to building a bootstrap compiler.


From: Gary Oblock 
Sent: Wednesday, September 29, 2021 11:55 AM
To: Toon Moene ; Erick Ochoa 
Cc: gcc@gcc.gnu.org 
Subject: Re: Can gcc itself be tested with ubsan? If so, how?

Toon,

I assume the final compiler built this way has ubsan? I ask because
I'm trying to spot a bug in a new optimization so I want to
run it on a specific test case with the new optimization
enabled.

Thanks,

Gary


From: Toon Moene 
Sent: Monday, September 27, 2021 11:47 PM
To: Erick Ochoa ; Gary Oblock 
Cc: gcc@gcc.gnu.org 
Subject: Re: Can gcc itself be tested with ubsan? If so, how?

[EXTERNAL EMAIL NOTICE: This email originated from an external sender. Please 
be mindful of safe email handling and proprietary information protection 
practices.]


On 9/28/21 8:35 AM, Erick Ochoa via Gcc wrote:

>> Can ubsan be used on the compiler itself?

I regularly build the compiler(s) natively with ubsan enabled, see for
instance:

https://gcc.gnu.org/pipermail/gcc-testresults/2021-September/719448.html

The configure line tells you how to do it (towards the end of the mail):

configure flags: --prefix=/home/toon/compilers/install/gcc --with-gnu-as
--with-gnu-ld --enable-languages=all,ada --disable-multilib
--disable-nls --with-build-config=bootstrap-ubsan --enable-checking=all

(the enable-checking part is not relevant, and can be omitted).

Kind regards,

--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands

-fchecking bug, what does it mean?

[Gary Oblock via Gcc]

Our test group added "-fchecking" to a script and my optimization
failed.

I can't find any explanation of this type of bug. I grepped the code
and flag_checking was all over the place so it's not like
I can use gdb to pin it down.

Can somebody help me make sense out of this?

lto1: error: type variant differs by TYPE_UNSIGNED
  constant 64>
unit-size  constant 8>
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 
0x7f399333a738 precision:64 min  max 
pointer_to_this >
  constant 64>
unit-size  constant 8>
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 
0x7f3992d1a3f0 precision:64 min  max 
pointer_to_this >
(null):0: confused by earlier errors, bailing out
lto-wrapper: fatal error: /home/gary/gcc_build_gcc11_v4/install/bin/gcc 
returned 1 exit status
compilation terminated.
[Leaving LTRANS ./exe.lto.o]
/usr/bin/ld: error: lto-wrapper failed
[Leaving exe.lto_wrapper_args]
collect2: error: ld returned 1 exit status

Thanks,

Gary


CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for 
the sole use of the intended recipient(s) and contains information that is 
confidential and proprietary to Ampere Computing or its subsidiaries. It is to 
be used solely for the purpose of furthering the parties' business 
relationship. Any unauthorized review, copying, or distribution of this email 
(or any attachments thereto) is strictly prohibited. If you are not the 
intended recipient, please contact the sender immediately and permanently 
delete the original and any copies of this email and any attachments thereto.

odd internal failure

[Gary Oblock via Gcc]

What is happening should be trivial to determine but for some reason it's
not. I'd normally bounce this off a coworker but given the pandemic
and modern dispersed hiring practices it's not even remotely possible.

I'm making this call and tree_to_uhwi is failing on an internal error.
That's normally easy to fix, but here is where the weirdness kicks in.

  unsigned HOST_WIDE_INT wi_offset = tree_to_uhwi (offset);

tree_to_uhwi from tree.h is:

extern inline __attribute__ ((__gnu_inline__)) unsigned HOST_WIDE_INT
tree_to_uhwi (const_tree t)
{
  gcc_assert (tree_fits_uhwi_p (t));
  return TREE_INT_CST_LOW (t);
}

and

tree_fits_uhwi_p from tree.c is

bool
tree_fits_uhwi_p (const_tree t)
{
  return (t != NULL_TREE
 && TREE_CODE (t) == INTEGER_CST
 && wi::fits_uhwi_p (wi::to_widest (t)));
}

Here's what this instrumentation shows (DEBUG_A is an indenting fprintf to
stderr.)

  DEBUG_A ("TREE_CODE(offset) = %s  && ", code_str (TREE_CODE (offset)));
  DEBUG_A ("fits %s\n", wi::fits_uhwi_p (wi::to_widest (offset)) ? "true" : 
"false");
  DEBUG_A ("tree_fits_uhwi_p(offset) %s\n",tree_fits_uhwi_p (offset) ? "true" : 
"false");

   TREE_CODE(offset) = INTEGER_CST  && fits true
   tree_fits_uhwi_p(offset) true

By the way, offset is:

_Literal (struct BASKET * *) 8

And it's an operand of:

MEM[(struct BASKET * *)&perm + 8B]

Any clues on what's going on here?

Thanks,

Gary


CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for 
the sole use of the intended recipient(s) and contains information that is 
confidential and proprietary to Ampere Computing or its subsidiaries. It is to 
be used solely for the purpose of furthering the parties' business 
relationship. Any unauthorized review, copying, or distribution of this email 
(or any attachments thereto) is strictly prohibited. If you are not the 
intended recipient, please contact the sender immediately and permanently 
delete the original and any copies of this email and any attachments thereto.

Re: odd internal failure

[Gary Oblock via Gcc]

Richard,

I rebuilt at "-O0" and that particular call now works but on a call to
the same function with a different offset it fails. 😱

Thanks,

Gary



From: Richard Biener 
Sent: Wednesday, December 1, 2021 1:09 AM
To: Gary Oblock 
Cc: gcc@gcc.gnu.org 
Subject: Re: odd internal failure

[EXTERNAL EMAIL NOTICE: This email originated from an external sender. Please 
be mindful of safe email handling and proprietary information protection 
practices.]


On Wed, Dec 1, 2021 at 8:46 AM Gary Oblock via Gcc  wrote:
>
> What is happening should be trivial to determine but for some reason it's
> not. I'd normally bounce this off a coworker but given the pandemic
> and modern dispersed hiring practices it's not even remotely possible.
>
> I'm making this call and tree_to_uhwi is failing on an internal error.
> That's normally easy to fix, but here is where the weirdness kicks in.
>
>   unsigned HOST_WIDE_INT wi_offset = tree_to_uhwi (offset);
>
> tree_to_uhwi from tree.h is:
>
> extern inline __attribute__ ((__gnu_inline__)) unsigned HOST_WIDE_INT
> tree_to_uhwi (const_tree t)
> {
>   gcc_assert (tree_fits_uhwi_p (t));
>   return TREE_INT_CST_LOW (t);
> }
>
> and
>
> tree_fits_uhwi_p from tree.c is
>
> bool
> tree_fits_uhwi_p (const_tree t)
> {
>   return (t != NULL_TREE
>  && TREE_CODE (t) == INTEGER_CST
>  && wi::fits_uhwi_p (wi::to_widest (t)));
> }
>
> Here's what this instrumentation shows (DEBUG_A is an indenting fprintf to
> stderr.)
>
>   DEBUG_A ("TREE_CODE(offset) = %s  && ", code_str (TREE_CODE (offset)));
>   DEBUG_A ("fits %s\n", wi::fits_uhwi_p (wi::to_widest (offset)) ? "true" : 
> "false");
>   DEBUG_A ("tree_fits_uhwi_p(offset) %s\n",tree_fits_uhwi_p (offset) ? "true" 
> : "false");
>
>TREE_CODE(offset) = INTEGER_CST  && fits true
>tree_fits_uhwi_p(offset) true
>
> By the way, offset is:
>
> _Literal (struct BASKET * *) 8
>
> And it's an operand of:
>
> MEM[(struct BASKET * *)&perm + 8B]
>
> Any clues on what's going on here?

it should just work.

> Thanks,
>
> Gary
>

Btw, try to setup things so you don't spam below stuff to public mailing lists.

> CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is 
> for the sole use of the intended recipient(s) and contains information that 
> is confidential and proprietary to Ampere Computing or its subsidiaries. It 
> is to be used solely for the purpose of furthering the parties' business 
> relationship. Any unauthorized review, copying, or distribution of this email 
> (or any attachments thereto) is strictly prohibited. If you are not the 
> intended recipient, please contact the sender immediately and permanently 
> delete the original and any copies of this email and any attachments thereto.

Re: odd internal failure

[Gary Oblock via Gcc]

David,

Thanks, I've bookmarked your advice. I do use gdb but I've always
found the macros in common use are the biggest hurdle. In addition
C++ has its own associated difficulties.

Note, in the past working on other compilers I've always tried to have
a function version of the macros available.

#if USE_FUNCTIONS
foo_t
MUMBLE( grumble_t *g)
{
  return FU( BAR(g));
}
#else
MUMBLE(g) FU(BAR(g))
#endif

There are many advantages to this. Some are, better type checking,
being able to step into them and invoke them in gdb "p MUMBLE(x)".

Thanks again,

Gary





From: David Malcolm 
Sent: Thursday, December 2, 2021 6:04 AM
To: Richard Biener ; Gary Oblock 

Cc: gcc@gcc.gnu.org 
Subject: Re: odd internal failure

[EXTERNAL EMAIL NOTICE: This email originated from an external sender. Please 
be mindful of safe email handling and proprietary information protection 
practices.]


On Thu, 2021-12-02 at 12:40 +0100, Richard Biener via Gcc wrote:
> On Wed, Dec 1, 2021 at 9:56 PM Gary Oblock 
> wrote:
> >
> > Richard,
> >
> > I rebuilt at "-O0" and that particular call now works but on a call
> > to
> > the same function with a different offset it fails. 😱
>
> use a debugger to see why

In case you haven't seen them, I put together some tips on debugging
GCC here:
https://dmalcolm.fedorapeople.org/gcc/newbies-guide/debugging.html
https://github.com/davidmalcolm/gcc-newbies-guide/blob/master/debugging.rst

Inserting print statements only gets you so far; at some point you
really need a debugger.

Dave

>
> > Thanks,
> >
> > Gary
> >
> >
> > 
> > From: Richard Biener 
> > Sent: Wednesday, December 1, 2021 1:09 AM
> > To: Gary Oblock 
> > Cc: gcc@gcc.gnu.org 
> > Subject: Re: odd internal failure
> >
> > [EXTERNAL EMAIL NOTICE: This email originated from an external
> > sender. Please be mindful of safe email handling and proprietary
> > information protection practices.]
> >
> >
> > On Wed, Dec 1, 2021 at 8:46 AM Gary Oblock via Gcc 
> > wrote:
> > >
> > > What is happening should be trivial to determine but for some
> > > reason it's
> > > not. I'd normally bounce this off a coworker but given the pandemic
> > > and modern dispersed hiring practices it's not even remotely
> > > possible.
> > >
> > > I'm making this call and tree_to_uhwi is failing on an internal
> > > error.
> > > That's normally easy to fix, but here is where the weirdness kicks
> > > in.
> > >
> > >   unsigned HOST_WIDE_INT wi_offset = tree_to_uhwi (offset);
> > >
> > > tree_to_uhwi from tree.h is:
> > >
> > > extern inline __attribute__ ((__gnu_inline__)) unsigned
> > > HOST_WIDE_INT
> > > tree_to_uhwi (const_tree t)
> > > {
> > >   gcc_assert (tree_fits_uhwi_p (t));
> > >   return TREE_INT_CST_LOW (t);
> > > }
> > >
> > > and
> > >
> > > tree_fits_uhwi_p from tree.c is
> > >
> > > bool
> > > tree_fits_uhwi_p (const_tree t)
> > > {
> > >   return (t != NULL_TREE
> > >  && TREE_CODE (t) == INTEGER_CST
> > >  && wi::fits_uhwi_p (wi::to_widest (t)));
> > > }
> > >
> > > Here's what this instrumentation shows (DEBUG_A is an indenting
> > > fprintf to
> > > stderr.)
> > >
> > >   DEBUG_A ("TREE_CODE(offset) = %s  && ", code_str (TREE_CODE
> > > (offset)));
> > >   DEBUG_A ("fits %s\n", wi::fits_uhwi_p (wi::to_widest (offset)) ?
> > > "true" : "false");
> > >   DEBUG_A ("tree_fits_uhwi_p(offset) %s\n",tree_fits_uhwi_p
> > > (offset) ? "true" : "false");
> > >
> > >TREE_CODE(offset) = INTEGER_CST  && fits true
> > >tree_fits_uhwi_p(offset) true
> > >
> > > By the way, offset is:
> > >
> > > _Literal (struct BASKET * *) 8
> > >
> > > And it's an operand of:
> > >
> > > MEM[(struct BASKET * *)&perm + 8B]
> > >
> > > Any clues on what's going on here?
> >
> > it should just work.
> >
> > > Thanks,
> > >
> > > Gary
> > >
> >
> > Btw, try to setup things so you don't spam below stuff to public
> > mailing lists.
> >
> > > CONFIDENTIALITY NOTICE: This e-mail message, including any
> > > attachments, is for the sole use of the intended recipient(s) and
> > > contains information that is confidential and proprietary to Ampere
> > > Computing or its subsidiaries. It is to be used solely for the
> > > purpose of furthering the parties' business relationship. Any
> > > unauthorized review, copying, or distribution of this email (or any
> > > attachments thereto) is strictly prohibited. If you are not the
> > > intended recipient, please contact the sender immediately and
> > > permanently delete the original and any copies of this email and
> > > any attachments thereto.
>

Why do these two trees print differently

[Gary Oblock via Gcc]

This is one of those things that has always puzzled
me so I thought I break down and finally ask.

There are two ways a memory reference (tree) prints:

MEM[(struct arc_t *)_684].flow

and

_684->flow

Poking under the hood of them, the tree codes and
operands are identical so what am I missing?

Thanks,

Gary


CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for 
the sole use of the intended recipient(s) and contains information that is 
confidential and proprietary to Ampere Computing or its subsidiaries. It is to 
be used solely for the purpose of furthering the parties' business 
relationship. Any unauthorized review, copying, or distribution of this email 
(or any attachments thereto) is strictly prohibited. If you are not the 
intended recipient, please contact the sender immediately and permanently 
delete the original and any copies of this email and any attachments thereto.

Re: Why do these two trees print differently

[Gary Oblock via Gcc]

Richard,

I was able figure it out by looking for "MEM" is
tree-pretty-print.c. There is the condition included
at the end of the email (mostly to provoke a chuckle)
necessary for the "p->f" format. If it's not true then
the MEM form is emitted.

What is most interesting from this whole exercise
the question of why am I seeing offsets in
the GIMPLE form? I'm seeing offsets where
the symbolic form using field seems to make
more sense. I'm also seeing accesses with
offsets that are multiples of the structure size.
That kind of idiom seems more appropriate at the
RTL level.

Thanks,

Gary

TREE_CODE (node) == MEM_REF
  && integer_zerop (TREE_OPERAND (node, 1))
  /* Dump the types of INTEGER_CSTs explicitly, for we can't
 infer them and MEM_ATTR caching will share MEM_REFs
 with differently-typed op0s.  */
  && TREE_CODE (TREE_OPERAND (node, 0)) != INTEGER_CST
  /* Released SSA_NAMES have no TREE_TYPE.  */
  && TREE_TYPE (TREE_OPERAND (node, 0)) != NULL_TREE
  /* Same pointer types, but ignoring POINTER_TYPE vs.
 REFERENCE_TYPE.  */
  && (TREE_TYPE (TREE_TYPE (TREE_OPERAND (node, 0)))
  == TREE_TYPE (TREE_TYPE (TREE_OPERAND (node, 1
  && (TYPE_MODE (TREE_TYPE (TREE_OPERAND (node, 0)))
  == TYPE_MODE (TREE_TYPE (TREE_OPERAND (node, 1
  && (TYPE_REF_CAN_ALIAS_ALL (TREE_TYPE (TREE_OPERAND (node, 0)))
  == TYPE_REF_CAN_ALIAS_ALL (TREE_TYPE (TREE_OPERAND (node, 1
  /* Same value types ignoring qualifiers.  */
  && (TYPE_MAIN_VARIANT (TREE_TYPE (node))
  == TYPE_MAIN_VARIANT
  (TREE_TYPE (TREE_TYPE (TREE_OPERAND (node, 1)
  && (!(flags & TDF_ALIAS)
  || MR_DEPENDENCE_CLIQUE (node) == 0))


From: Richard Biener 
Sent: Monday, January 3, 2022 5:49 AM
To: Gary Oblock 
Cc: gcc@gcc.gnu.org 
Subject: Re: Why do these two trees print differently

[EXTERNAL EMAIL NOTICE: This email originated from an external sender. Please 
be mindful of safe email handling and proprietary information protection 
practices.]


On Wed, Dec 15, 2021 at 7:10 AM Gary Oblock via Gcc  wrote:
>
> This is one of those things that has always puzzled
> me so I thought I break down and finally ask.
>
> There are two ways a memory reference (tree) prints:
>
> MEM[(struct arc_t *)_684].flow
>
> and
>
> _684->flow
>
> Poking under the hood of them, the tree codes and
> operands are identical so what am I missing?

Try dumping with -gimple, that should show you the difference.

>
> Thanks,
>
> Gary
>
>
> CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is 
> for the sole use of the intended recipient(s) and contains information that 
> is confidential and proprietary to Ampere Computing or its subsidiaries. It 
> is to be used solely for the purpose of furthering the parties' business 
> relationship. Any unauthorized review, copying, or distribution of this email 
> (or any attachments thereto) is strictly prohibited. If you are not the 
> intended recipient, please contact the sender immediately and permanently 
> delete the original and any copies of this email and any attachments thereto.

Re: Why do these two trees print differently

[Gary Oblock via Gcc]

Richard,

Well during my exploration of pretty printing I spent
a bunch of time looking at mem refs, hence the question.

I understand GIMPLE is not an AST. I worked on a
in house compiler someplace where the only IR was
an AST and it was a really horrible IR so I'm glad GIMPLE
isn't an AST. But the tree expressions seem to be chunks
of AST (with some other stuff thrown in that could be thought of
as node attributes.) Am I wrong to think of them that way?

Thanks,

Gary



From: Richard Biener 
Sent: Monday, January 3, 2022 11:28 PM
To: Gary Oblock 
Cc: gcc@gcc.gnu.org 
Subject: Re: Why do these two trees print differently

[EXTERNAL EMAIL NOTICE: This email originated from an external sender. Please 
be mindful of safe email handling and proprietary information protection 
practices.]


On Mon, Jan 3, 2022 at 9:16 PM Gary Oblock  wrote:
>
> Richard,
>
> I was able figure it out by looking for "MEM" is
> tree-pretty-print.c. There is the condition included
> at the end of the email (mostly to provoke a chuckle)
> necessary for the "p->f" format. If it's not true then
> the MEM form is emitted.

Yes, there's some loss of information so we don't
"pretty" print the MEM.

>
> What is most interesting from this whole exercise
> the question of why am I seeing offsets in
> the GIMPLE form? I'm seeing offsets where
> the symbolic form using field seems to make
> more sense. I'm also seeing accesses with
> offsets that are multiples of the structure size.
> That kind of idiom seems more appropriate at the
> RTL level.

That seems to be an unrelated question?  Note that GIMPLE
is much closer to RTL than you think - GIMPLE is _not_ an AST.
You see offsets whenever symbolic (COMPONENT_REF I suppose)
is eventually not semantically correct.

Richard.

>
> Thanks,
>
> Gary
>
> TREE_CODE (node) == MEM_REF
>   && integer_zerop (TREE_OPERAND (node, 1))
>   /* Dump the types of INTEGER_CSTs explicitly, for we can't
>  infer them and MEM_ATTR caching will share MEM_REFs
>  with differently-typed op0s.  */
>   && TREE_CODE (TREE_OPERAND (node, 0)) != INTEGER_CST
>   /* Released SSA_NAMES have no TREE_TYPE.  */
>   && TREE_TYPE (TREE_OPERAND (node, 0)) != NULL_TREE
>   /* Same pointer types, but ignoring POINTER_TYPE vs.
>  REFERENCE_TYPE.  */
>   && (TREE_TYPE (TREE_TYPE (TREE_OPERAND (node, 0)))
>   == TREE_TYPE (TREE_TYPE (TREE_OPERAND (node, 1
>   && (TYPE_MODE (TREE_TYPE (TREE_OPERAND (node, 0)))
>   == TYPE_MODE (TREE_TYPE (TREE_OPERAND (node, 1
>   && (TYPE_REF_CAN_ALIAS_ALL (TREE_TYPE (TREE_OPERAND (node, 0)))
>   == TYPE_REF_CAN_ALIAS_ALL (TREE_TYPE (TREE_OPERAND (node, 1
>   /* Same value types ignoring qualifiers.  */
>   && (TYPE_MAIN_VARIANT (TREE_TYPE (node))
>   == TYPE_MAIN_VARIANT
>   (TREE_TYPE (TREE_TYPE (TREE_OPERAND (node, 1)
>   && (!(flags & TDF_ALIAS)
>   || MR_DEPENDENCE_CLIQUE (node) == 0))
>
> 
> From: Richard Biener 
> Sent: Monday, January 3, 2022 5:49 AM
> To: Gary Oblock 
> Cc: gcc@gcc.gnu.org 
> Subject: Re: Why do these two trees print differently
>
> [EXTERNAL EMAIL NOTICE: This email originated from an external sender. Please 
> be mindful of safe email handling and proprietary information protection 
> practices.]
>
>
> On Wed, Dec 15, 2021 at 7:10 AM Gary Oblock via Gcc  wrote:
> >
> > This is one of those things that has always puzzled
> > me so I thought I break down and finally ask.
> >
> > There are two ways a memory reference (tree) prints:
> >
> > MEM[(struct arc_t *)_684].flow
> >
> > and
> >
> > _684->flow
> >
> > Poking under the hood of them, the tree codes and
> > operands are identical so what am I missing?
>
> Try dumping with -gimple, that should show you the difference.
>
> >
> > Thanks,
> >
> > Gary
> >
> >
> > CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is 
> > for the sole use of the intended recipient(s) and contains information that 
> > is confidential and proprietary to Ampere Computing or its subsidiaries. It 
> > is to be used solely for the purpose of furthering the parties' business 
> > relationship. Any unauthorized review, copying, or distribution of this 
> > email (or any attachments thereto) is strictly prohibited. If you are not 
> > the intended recipient, please contact the sender immediately and 
> > permanently delete the original and any copies of this email and any 
> > attachments thereto.

Issue with a flag that I defined getting set to zero

[Gary Oblock via Gcc]

An optimization flag that I recently added is being
set to zero in push_cfun (which after a couple of
levels of calls cl_optimization_restore to this.)

The flag defined like this:

finterleaving-index-32-bits
Common Var(flag_interleaving_index_32_bits) Init(0) Optimization
Structure reorganization optimization, instance interleaving.

Note, I'm working around this but l'd really like
to not have to do so therefore I'm wondering if somebody
could explain what's happening and what I'd need
to do instead?

Thanks,

Gary


CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for 
the sole use of the intended recipient(s) and contains information that is 
confidential and proprietary to Ampere Computing or its subsidiaries. It is to 
be used solely for the purpose of furthering the parties' business 
relationship. Any unauthorized review, copying, or distribution of this email 
(or any attachments thereto) is strictly prohibited. If you are not the 
intended recipient, please contact the sender immediately and permanently 
delete the original and any copies of this email and any attachments thereto.

Re: Issue with a flag that I defined getting set to zero

[Gary Oblock via Gcc]

Martin,

Regarding the corporate legal gibberish. It's automatic
and not under my control also we're not supposed to
use private emails for work...

Gary

From: Martin Liška 
Sent: Friday, January 7, 2022 12:20 AM
To: Gary Oblock ; gcc@gcc.gnu.org 
Subject: Re: Issue with a flag that I defined getting set to zero

[EXTERNAL EMAIL NOTICE: This email originated from an external sender. Please 
be mindful of safe email handling and proprietary information protection 
practices.]


On 1/7/22 09:10, Gary Oblock via Gcc wrote:
> An optimization flag that I recently added is being
> set to zero in push_cfun (which after a couple of
> levels of calls cl_optimization_restore to this.)

Question is: what's the value of the flag in your IPA pass
if you set -finterleaving-index-32-bits? It should not really be zero.

>
> The flag defined like this:
>
> finterleaving-index-32-bits
> Common Var(flag_interleaving_index_32_bits) Init(0) Optimization
> Structure reorganization optimization, instance interleaving.
>
> Note, I'm working around this but l'd really like
> to not have to do so therefore I'm wondering if somebody
> could explain what's happening and what I'd need
> to do instead?

You defined the flag well.

>
> Thanks,
>
> Gary
>
>
> CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is 
> for the sole use of the intended recipient(s) and contains information that 
> is confidential and proprietary to Ampere Computing or its subsidiaries. It 
> is to be used solely for the purpose of furthering the parties' business 
> relationship. Any unauthorized review, copying, or distribution of this email 
> (or any attachments thereto) is strictly prohibited. If you are not the 
> intended recipient, please contact the sender immediately and permanently 
> delete the original and any copies of this email and any attachments thereto.

Can you please remove this ugly notice that it's completely misleading? If not, 
I would then
recommend creating a private email.

Martin

Re: Issue with a flag that I defined getting set to zero

[Gary Oblock via Gcc]

Gabriel,

Yes, indeed, thank you.

Note, it is a reminder to those that are receiving proprietary
and that is considered as a legal obligation on the part of the
company transmitting it because they must make an effort to
protect their proprietary information.

I'm not a lawyer either but I feel like I'm being forced to
act like one. 😉

Now, can anybody answer my question?

Sincerely

Gary


From: Gabriel Ravier 
Sent: Friday, January 7, 2022 12:56 AM
To: Martin Liška ; Gary Oblock ; 
gcc@gcc.gnu.org 
Subject: Re: Issue with a flag that I defined getting set to zero

[EXTERNAL EMAIL NOTICE: This email originated from an external sender. Please 
be mindful of safe email handling and proprietary information protection 
practices.]


On 1/7/22 09:38, Martin Liška wrote:
> On 1/7/22 09:30, Gary Oblock wrote:
>> Regarding the corporate legal gibberish. It's automatic
>> and not under my control also we're not supposed to
>> use private emails for work...
>
> I respect that. But please respect me that I won't reply to your
> emails any longer. I don't want to follow the conditions in the NOTICE!
>
> Cheers,
> Martin
>
As far as I know the notice has no legal significance at all (which Gary
should probably point out to his management. Really, pretty much the
only thing the disclaimer will do is that _some_ people _might_ read it
and _some_ of those people _might_ adhere to the terms given there,
which is basically meaningless compared to the general annoyance
resulting from disclaimers being at the end of e-mails everywhere). You
can't just magically establish an agreement that results in a duty of
nondisclosure like this without agreement, and just receiving an email
obviously isn't that.

(although ironically, I guess I should add a disclaimer of my own: I
ain't a lawyer and this isn't legal advice)

Re: Issue with a flag that I defined getting set to zero

[Gary Oblock via Gcc]

Richard,

That's nice to know but I added the option itself months ago.
Also, it's on the lto1 command line, cc1 command line and
shows up in the COLLECT_GCC_OPTIONS so I assume
it universally applied.

Thanks,

Gary

From: Richard Biener 
Sent: Monday, January 10, 2022 12:36 AM
To: Gary Oblock 
Cc: gcc@gcc.gnu.org 
Subject: Re: Issue with a flag that I defined getting set to zero

[EXTERNAL EMAIL NOTICE: This email originated from an external sender. Please 
be mindful of safe email handling and proprietary information protection 
practices.]


On Fri, Jan 7, 2022 at 9:12 AM Gary Oblock via Gcc  wrote:
>
> An optimization flag that I recently added is being
> set to zero in push_cfun (which after a couple of
> levels of calls cl_optimization_restore to this.)
>
> The flag defined like this:
>
> finterleaving-index-32-bits
> Common Var(flag_interleaving_index_32_bits) Init(0) Optimization
> Structure reorganization optimization, instance interleaving.
>
> Note, I'm working around this but l'd really like
> to not have to do so therefore I'm wondering if somebody
> could explain what's happening and what I'd need
> to do instead?

Did you rebuild all of GCC after adding the option?  Note that when you
look at the option from LTO and from within an IPA pass then you
have to use opt_for_fn (..) since the "global" option at link time will
be not set (unless you specify it again at link time), it will be only
present on the functions of the compile TU it was set globally.

>
> Thanks,
>
> Gary
>
>
> CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is 
> for the sole use of the intended recipient(s) and contains information that 
> is confidential and proprietary to Ampere Computing or its subsidiaries. It 
> is to be used solely for the purpose of furthering the parties' business 
> relationship. Any unauthorized review, copying, or distribution of this email 
> (or any attachments thereto) is strictly prohibited. If you are not the 
> intended recipient, please contact the sender immediately and permanently 
> delete the original and any copies of this email and any attachments thereto.

Re: Benchmark recommendations needed

[Gary Oblock via Gcc]

Trying to use the dhrystone isn't going to be very useful. It has many 
downsides not the least is that gcc's optimizer can run rings about it.

Gary


From: Gcc  on behalf of 
gcc-requ...@gcc.gnu.org 
Sent: Tuesday, February 15, 2022 6:25 AM
To: gcc@gcc.gnu.org 
Subject: Re:

[EXTERNAL EMAIL NOTICE: This email originated from an external sender. Please 
be mindful of safe email handling and proprietary information protection 
practices.]


Send Gcc mailing list submissions to
gcc@gcc.gnu.org

To subscribe or unsubscribe via the World Wide Web, visit
https://gcc.gnu.org/mailman/listinfo/gcc
or, via email, send a message with subject or body 'help' to
gcc-requ...@gcc.gnu.org

You can reach the person managing the list at
gcc-ow...@gcc.gnu.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Gcc digest..."

Re: Benchmark recommendations needed

[Gary Oblock via Gcc]

Andras,

The whole point of benchmarks is to judge a processor's performance.
That being said, just crippling GCC is not reasonable because
processors must be judged in the appropriate context and that
includes the current state of the art compiler technology. If you have
a new processor I'd benchmark it using the applications you built it
for.

Gary


From: Andras Tantos 
Sent: Monday, February 21, 2022 9:22 PM
To: Gary Oblock ; gcc@gcc.gnu.org 
Subject: Re: Benchmark recommendations needed

[EXTERNAL EMAIL NOTICE: This email originated from an external sender. Please 
be mindful of safe email handling and proprietary information protection 
practices.]


That's true, I did notice GCC being rather ... peculiar about
drhystone. Is there a way to make it less clever about the benchmark?

Or is there some alteration to the benchmark I can make to not trigger
the special behavior in GCC?

Andras

On Mon, 2022-02-21 at 03:19 +0000, Gary Oblock via Gcc wrote:
> Trying to use the dhrystone isn't going to be very useful. It has
> many downsides not the least is that gcc's optimizer can run rings
> about it.
>
> Gary
>
> 
> From: Gcc  on
> behalf of gcc-requ...@gcc.gnu.org 
> Sent: Tuesday, February 15, 2022 6:25 AM
> To: gcc@gcc.gnu.org 
> Subject: Re:
>
> [EXTERNAL EMAIL NOTICE: This email originated from an external
> sender. Please be mindful of safe email handling and proprietary
> information protection practices.]
>
>
> Send Gcc mailing list submissions to
> gcc@gcc.gnu.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://gcc.gnu.org/mailman/listinfo/gcc
> or, via email, send a message with subject or body 'help' to
> gcc-requ...@gcc.gnu.org
>
> You can reach the person managing the list at
> gcc-ow...@gcc.gnu.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Gcc digest..."

What replaces FOR_EACH_LOOP_FN

[Gary Oblock via Gcc]

Guys,

I've been working on an optimization for quite a bit of time and
in an attempt to move it to GCC 12 I found that FOR_EACH_LOOP_FN
no longer exists. I poked around in the archives and tried a Google
search but found nothing on it.

It suited my needs and I'd hate to have to rewrite a bunch of stuff.
What replaces it and how do I use?

Thanks,

Gary




CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for 
the sole use of the intended recipient(s) and contains information that is 
confidential and proprietary to Ampere Computing or its subsidiaries. It is to 
be used solely for the purpose of furthering the parties' business 
relationship. Any unauthorized review, copying, or distribution of this email 
(or any attachments thereto) is strictly prohibited. If you are not the 
intended recipient, please contact the sender immediately and permanently 
delete the original and any copies of this email and any attachments thereto.

Re: What replaces FOR_EACH_LOOP_FN

[Gary Oblock via Gcc]

Andrew,

That's super! I was dreading an answer along the lines
of "we don't do that anymore so why would you ever want
to do that?" 😉

Many thanks,

Gary

From: Andrew Pinski 
Sent: Wednesday, March 2, 2022 2:09 PM
To: Gary Oblock 
Cc: gcc@gcc.gnu.org 
Subject: Re: What replaces FOR_EACH_LOOP_FN

[EXTERNAL EMAIL NOTICE: This email originated from an external sender. Please 
be mindful of safe email handling and proprietary information protection 
practices.]


On Wed, Mar 2, 2022 at 2:05 PM Gary Oblock via Gcc  wrote:
>
> Guys,
>
> I've been working on an optimization for quite a bit of time and
> in an attempt to move it to GCC 12 I found that FOR_EACH_LOOP_FN
> no longer exists. I poked around in the archives and tried a Google
> search but found nothing on it.
>
> It suited my needs and I'd hate to have to rewrite a bunch of stuff.
> What replaces it and how do I use?

This changed with r12-2605-ge41ba804ba5f5c. The replacement is just simply:

for (auto loop : loops_list (function, 0))

Thanks,
Andrew Pinski


>
> Thanks,
>
> Gary
>
>
>
>
> CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is 
> for the sole use of the intended recipient(s) and contains information that 
> is confidential and proprietary to Ampere Computing or its subsidiaries. It 
> is to be used solely for the purpose of furthering the parties' business 
> relationship. Any unauthorized review, copying, or distribution of this email 
> (or any attachments thereto) is strictly prohibited. If you are not the 
> intended recipient, please contact the sender immediately and permanently 
> delete the original and any copies of this email and any attachments thereto.

Re: Question on updating function body on specialized functions

[Gary Oblock via Gcc]

Erick my friend,

That's exactly why I'm such a big fan of creating things
anew each time I mess with them.  😉

Later,

Gary


From: Erick Ochoa 
Sent: Tuesday, March 8, 2022 7:29 AM
To: Martin Jambor 
Cc: gcc@gcc.gnu.org 
Subject: Re: Question on updating function body on specialized functions

Hi Martin!

Thanks for replying, turns out that while I was trying to reply to you I
was able to get the answer. Turns out there is indeed one tree node which
is shared across the two functions. And that is

TREE_OPERAND (MEM_REF, 1).

When I was assigning to

TREE_TYPE ( TREE_OPERAND (MEM_REF, 1) ) in one function, I was modifying
the other. The solution was to create a new tree and assign it directly to
TREE_OPERAND (MEM_REF, 1) in both functions.

Thanks!