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

[David Blaikie via llvm-dev]

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:
>>
>> "artificialThis 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://reviews.llvm.org/D43259#change-jbvcnfxttyAz>
>>>
>>> And according to the specification
>>> <https://clang.llvm.org/docs/AttributeReference.html#artificial> 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://godbolt.org/z/oW8Td5d4M>
>>>
>>> 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
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20220128/c59628f7/attachment.html>