thr3ads.net - llvm dev - [llvm-dev] about __attribute__((artificial)) and inline pass [Jan 2022]

If this information is useful, please help other people find it:
Share via:

Robinson, Paul via llvm-dev

2022-Jan-28 20:07 UTC

[llvm-dev] about attribute((artificial)) and inline pass

In order to get the described effect, I think we’d need to put DW_AT_artificial
on the subprogram, and then not attach source locations to the generated code. 
That would have the effect of not allowing break/step inside, but the subprogram
name is still available. This is not the same as `nodebug`, where you lose the
subprogram name too.
Shouldn’t be at all hard to get this to work.

Fangqing, would you be able to file an issue for this?
Thanks,
--paulr

From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of David
Blaikie via llvm-dev
Sent: Friday, January 28, 2022 2:37 PM
To: Reid Kleckner <rnk at google.com>
Cc: llvm-dev <llvm-dev at lists.llvm.org>
Subject: Re: [llvm-dev] about __attribute__((artificial)) and inline pass

On Fri, Jan 28, 2022 at 11:26 AM Reid Kleckner <rnk at
google.com<mailto:rnk at google.com>> wrote:
I thought `artificial` and `nodebug` were supposed to be synonyms, just
different names invented by different communities.

Doesn't look like it, based on the GCC documentation and behavior - GCC puts
the DW_AT_artificial attribute on the entity, but still fully describes it
(DWARF remains the same except for that attribute). I think the second option in
the GCC docs is for debug info formats that don't have an equivalent of
DW_AT_artificial, in which case it downgrades to the equivalent of
"nodebug".

The linked patch doesn't implement the LLVM side of things, so I'm not
sure when that got added.

The patch added the artificial flag on the metadata which was already
implemented/supported in LLVM (used for things like implicit constructors, etc,
which don't have user-written code in them) and matches the GCC behavior -
no extra work was needed on the LLVM side.


On Fri, Jan 28, 2022 at 11:03 AM David Blaikie <dblaikie at
gmail.com<mailto:dblaikie at gmail.com>> wrote:
Hmm, seems I missed this feature (or at least don't remember) when it went
in.

Looks like the GCC spec might be more accurate to the current implementation
than what Clang's documentation says:

"artificial
This attribute is useful for small inline wrappers which if possible should
appear during debugging as a unit, depending on the debug info format it will
either mean marking the function as artificial or using the caller location for
all instructions within the inlined body."

& the "marking the function as artificial" is the thing that this
patch implemented in Clang. This did not have the same effect as nodebug, and
doesn't "use the caller location for all instructions within the
inlined body".

It's possible we could implement the "artificial" attribute as a
an alias for "nodebug" which would also be conforming with GCC's
spec, but would be less expressive than the current implementation (though would
save debug info size in a way the current Clang implementation does not).

It looks like Clang's implementation is consistent with GCC's
implementation for DWARF - "marking the function as artificial", not
"using the caller location for instructions within the inlined body",
but Clang's documentation is incorrect, since it documents the latter and
not the former.

On Fri, Jan 28, 2022 at 9:44 AM Fangqing Du via llvm-dev <llvm-dev at
lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:
Dear all,

In clang/llvm 7.0, `__attribute__((artificial))` can be identified by clang and
attach `DIFlagArtificial` into function metadata in this
change.<https://urldefense.com/v3/__https:/reviews.llvm.org/D43259*change-jbvcnfxttyAz__;Iw!!JmoZiZGBv3RvKRSx!pEsMF8kDNPtKteuvhreMp6mZjOVtB-7XVCgfOi_ELf630AbjxHC2VDLB3BoX9IMFWg$>

And according to the
specification<https://urldefense.com/v3/__https:/clang.llvm.org/docs/AttributeReference.html*artificial__;Iw!!JmoZiZGBv3RvKRSx!pEsMF8kDNPtKteuvhreMp6mZjOVtB-7XVCgfOi_ELf630AbjxHC2VDLB3BrUKhXpvw$>
of `artificial`, if I understand correctly, when the function (which is marked
with `artificial` attribute) is inlined, the inlined function instructions
should be associated with the callsite line number, instead of the line of
inlined callee.

But from my observation, with and without this attribute, the inline pass
behavior is not affected, and inlined instructions debug location still point to
the callee instead of callsite.
Here is my experiment: godbolt experiment
link<https://urldefense.com/v3/__https:/godbolt.org/z/oW8Td5d4M__;!!JmoZiZGBv3RvKRSx!pEsMF8kDNPtKteuvhreMp6mZjOVtB-7XVCgfOi_ELf630AbjxHC2VDLB3BqqabukgA$>

Is my understanding correct?
Thanks,
Fangqing
Xilinx Inc.

== ------------ example -------------==
  1 int bar(int);

  2

  3 inline int __attribute__((artificial)) __attribute__((always_inline))
foo(int x)

  4 {

  5     return bar(x + 1);

  6 }

  7

  8 void baz(void)

  9 {

 10     auto x = foo(1);

 11     x = foo(2);

 12 }

When function 'foo' is inlined, the debug location of call instruction
'bar' still points to line #5, instead of line #10 and #11.
_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev<https://urldefense.com/v3/__https:/lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev__;!!JmoZiZGBv3RvKRSx!pEsMF8kDNPtKteuvhreMp6mZjOVtB-7XVCgfOi_ELf630AbjxHC2VDLB3Bp86eErug$>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20220128/6a33d02c/attachment.html>

David Blaikie via llvm-dev

2022-Jan-28 20:31 UTC

head link

[llvm-dev] about attribute((artificial)) and inline pass

On Fri, Jan 28, 2022 at 12:07 PM Robinson, Paul <paul.robinson at
sony.com>
wrote:
> In order to get the described effect, I think we’d need to put
> DW_AT_artificial on the subprogram, and then not attach source locations to
> the generated code.  That would have the effect of not allowing break/step
> inside, but the subprogram name is still available. This is not the same as
> `nodebug`, where you lose the subprogram name too.
>
> Shouldn’t be at all hard to get this to work.
>
That doesn't seem to be the described or actual effect (testing GCC's
debug
info, even for __attribute__((artificial)) functions, the locations inside
the function (inlined or non-inlined) are attributed to their original
source location, not to the call site) - I believe the intent is that only
effect of the attribute is to add the DW_AT_artificial attribute to the
function (& that seems to be the implemented effect) - but if GCC is
emitting some other debug info format (not sure what other formats it
supports) that doesn't have an equivalent to DW_AT_artificial, it does the
next best thing - which is to attribute the inlined source locations to the
call site. (unclear what it does for non-inlined code in that case - though
interestingly the attribute is only valid in GCC on functions that are
marked "inline"... which seems like a weird limitation to me).

I believe Clang is implementing the same behavior as GCC, as far as DWARF
is concerned at least. It appears to be a documentation issue to me.

- Dave

>
>
> Fangqing, would you be able to file an issue for this?
>
> Thanks,
>
> --paulr
>
>
>
> *From:* llvm-dev <llvm-dev-bounces at lists.llvm.org> *On Behalf Of
*David
> Blaikie via llvm-dev
> *Sent:* Friday, January 28, 2022 2:37 PM
> *To:* Reid Kleckner <rnk at google.com>
> *Cc:* llvm-dev <llvm-dev at lists.llvm.org>
> *Subject:* Re: [llvm-dev] about __attribute__((artificial)) and inline
> pass
>
>
>
> On Fri, Jan 28, 2022 at 11:26 AM Reid Kleckner <rnk at google.com>
wrote:
>
> I thought `artificial` and `nodebug` were supposed to be synonyms, just
> different names invented by different communities.
>
>
> Doesn't look like it, based on the GCC documentation and behavior - GCC
> puts the DW_AT_artificial attribute on the entity, but still fully
> describes it (DWARF remains the same except for that attribute). I think
> the second option in the GCC docs is for debug info formats that don't
have
> an equivalent of DW_AT_artificial, in which case it downgrades to the
> equivalent of "nodebug".
>
>
> The linked patch doesn't implement the LLVM side of things, so I'm
not
> sure when that got added.
>
>
> The patch added the artificial flag on the metadata which was already
> implemented/supported in LLVM (used for things like implicit constructors,
> etc, which don't have user-written code in them) and matches the GCC
> behavior - no extra work was needed on the LLVM side.
>
>
>
>
> On Fri, Jan 28, 2022 at 11:03 AM David Blaikie <dblaikie at
gmail.com> wrote:
>
> Hmm, seems I missed this feature (or at least don't remember) when it
went
> in.
>
> Looks like the GCC spec might be more accurate to the current
> implementation than what Clang's documentation says:
>
> "artificial
>
> This attribute is useful for small inline wrappers which if possible
> should appear during debugging as a unit, depending on the debug info
> format it will either mean marking the function as artificial or using the
> caller location for all instructions within the inlined body."
>
>
> & the "marking the function as artificial" is the thing that
this patch
> implemented in Clang. This did not have the same effect as nodebug, and
> doesn't "use the caller location for all instructions within the
inlined
> body".
>
> It's possible we could implement the "artificial" attribute
as a an alias
> for "nodebug" which would also be conforming with GCC's spec,
but would be
> less expressive than the current implementation (though would save debug
> info size in a way the current Clang implementation does not).
>
> It looks like Clang's implementation is consistent with GCC's
> implementation for DWARF - "marking the function as artificial",
not "using
> the caller location for instructions within the inlined body", but
Clang's
> documentation is incorrect, since it documents the latter and not the
> former.
>
>
>
> On Fri, Jan 28, 2022 at 9:44 AM Fangqing Du via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
> Dear all,
>
>
>
> In clang/llvm 7.0, `__attribute__((artificial))` can be identified by
> clang and attach `DIFlagArtificial` into function metadata in this change.
>
<https://urldefense.com/v3/__https:/reviews.llvm.org/D43259*change-jbvcnfxttyAz__;Iw!!JmoZiZGBv3RvKRSx!pEsMF8kDNPtKteuvhreMp6mZjOVtB-7XVCgfOi_ELf630AbjxHC2VDLB3BoX9IMFWg$>
>
>
>
> And according to the specification
>
<https://urldefense.com/v3/__https:/clang.llvm.org/docs/AttributeReference.html*artificial__;Iw!!JmoZiZGBv3RvKRSx!pEsMF8kDNPtKteuvhreMp6mZjOVtB-7XVCgfOi_ELf630AbjxHC2VDLB3BrUKhXpvw$>
> of `artificial`, if I understand correctly, when the function (which is
> marked with `artificial` attribute) is inlined, the inlined function
> instructions should be associated with the callsite line number, instead of
> the line of inlined callee.
>
>
>
> But from my observation, with and without this attribute, the inline pass
> behavior is not affected, and inlined instructions debug location still
> point to the callee instead of callsite.
>
> Here is my experiment: godbolt experiment link
>
<https://urldefense.com/v3/__https:/godbolt.org/z/oW8Td5d4M__;!!JmoZiZGBv3RvKRSx!pEsMF8kDNPtKteuvhreMp6mZjOVtB-7XVCgfOi_ELf630AbjxHC2VDLB3BqqabukgA$>
>
>
>
> Is my understanding correct?
>
> Thanks,
>
> Fangqing
>
> Xilinx Inc.
>
>
>
> == ------------ example -------------==>
>   1 int bar(int);
>
>   2
>
>   3 inline int __attribute__((artificial)) __attribute__((always_inline))
> foo(int x)
>
>   4 {
>
>   5     return bar(x + 1);
>
>   6 }
>
>   7
>
>   8 void baz(void)
>
>   9 {
>
>  10     auto x = foo(1);
>
>  11     x = foo(2);
>
>  12 }
>
>
>
> When function 'foo' is inlined, the debug location of call
instruction
> 'bar' still points to line #5, instead of line #10 and #11.
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
<https://urldefense.com/v3/__https:/lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev__;!!JmoZiZGBv3RvKRSx!pEsMF8kDNPtKteuvhreMp6mZjOVtB-7XVCgfOi_ELf630AbjxHC2VDLB3Bp86eErug$>
>
>-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20220128/a55eb044/attachment.html>

llvm dev - Jan 2022 - about __attribute__((artificial)) and inline pass

[llvm-dev] about __attribute__((artificial)) and inline pass

[llvm-dev] about __attribute__((artificial)) and inline pass

llvm dev - Jan 2022 - about attribute((artificial)) and inline pass

[llvm-dev] about attribute((artificial)) and inline pass

[llvm-dev] about attribute((artificial)) and inline pass