public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* A problem with field decl offsets in newly minted types
@ 2020-12-31  7:00 Gary Oblock
  2021-01-01 21:14 ` Gary Oblock
  0 siblings, 1 reply; 3+ messages in thread
From: Gary Oblock @ 2020-12-31  7:00 UTC (permalink / raw)
  To: 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.

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: A problem with field decl offsets in newly minted types
  2020-12-31  7:00 A problem with field decl offsets in newly minted types Gary Oblock
@ 2021-01-01 21:14 ` Gary Oblock
  2021-01-04 13:59   ` Richard Biener
  0 siblings, 1 reply; 3+ messages in thread
From: Gary Oblock @ 2021-01-01 21:14 UTC (permalink / raw)
  To: 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 <gary@amperecomputing.com>
Sent: Wednesday, December 30, 2020 11:00 PM
To: gcc@gcc.gnu.org <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.


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: A problem with field decl offsets in newly minted types
  2021-01-01 21:14 ` Gary Oblock
@ 2021-01-04 13:59   ` Richard Biener
  0 siblings, 0 replies; 3+ messages in thread
From: Richard Biener @ 2021-01-04 13:59 UTC (permalink / raw)
  To: Gary Oblock; +Cc: gcc

On Fri, Jan 1, 2021 at 10:16 PM Gary Oblock via Gcc <gcc@gcc.gnu.org> wrote:
>
> The offsets seem to actually be created. However,
> they are almost immediately are being deleted.

Use a watchpoint to see where.

> 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 <gary@amperecomputing.com>
> Sent: Wednesday, December 30, 2020 11:00 PM
> To: gcc@gcc.gnu.org <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.
>

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2021-01-04 13:59 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-12-31  7:00 A problem with field decl offsets in newly minted types Gary Oblock
2021-01-01 21:14 ` Gary Oblock
2021-01-04 13:59   ` Richard Biener

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).