Types are confused in inlining

Types are confused in inlining

[Gary Oblock]

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

[Richard Biener]

On Wed, Sep 2, 2020 at 10:19 PM Gary Oblock via Gcc <gcc@gcc.gnu.org> 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.

Re: Types are confused in inlining

[Gary Oblock]

>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 <richard.guenther@gmail.com>
Sent: Wednesday, September 2, 2020 11:31 PM
To: Gary Oblock <gary@amperecomputing.com>
Cc: gcc@gcc.gnu.org <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 <gcc@gcc.gnu.org> 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.

Re: Types are confused in inlining

[Richard Biener]

On September 3, 2020 7:59:12 PM GMT+02:00, Gary Oblock <gary@amperecomputing.com> wrote:
>>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. 😉

Ah, well. It's probably your own code that is 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???

I never had an issue with watch points. 

Richard. 

>Thanks,
>
>Gary
>________________________________
>From: Richard Biener <richard.guenther@gmail.com>
>Sent: Wednesday, September 2, 2020 11:31 PM
>To: Gary Oblock <gary@amperecomputing.com>
>Cc: gcc@gcc.gnu.org <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 <gcc@gcc.gnu.org>
>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.