<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div> </div>
<div>RE: Message 3:</div>
<div>2. Create a batch to call Clang (shirley breuer via cfe-dev)<br/>
3. Re: Create a batch to call Clang (David Blaikie via cfe-dev)</div>
<div> </div>
<div>
<div>
<div>How would that work? </div>
<div><br/>
I want to create a batch file that I can apply and open in all programs (TI Code Composer, Eclipse IDE and ARM Keil). <br/>
The idea should be that my batch file edits/uses Clang to format. </div>
<div>The batch file could also be created to be hooked in as a pre-build step. </div>
<div>If there is an easier solution for this that I can use across TI Code Composer, Eclipse IDE, and ARM Keil integration, I'd be happy to take those suggestions. </div>
<div> </div>
<div>The aim of this is to have my source code conform to a certain layout. </div>
<div><br/>
Integration of Clang into TI Code Composer, Eclipse IDE and ARM Keil to get unified source code with certain layout. </div>
<div>In the attachment I attach gladly the document. </div>
<div> </div>
<div>I hope you can help me! :) </div>
<div> </div>
<div>Best regards</div>
<div>Shirley </div>
<div name="quote" style="margin:10px 5px 5px 10px; padding: 10px 0 10px 10px; border-left:2px solid #C3D9E5; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">
<div style="margin:0 0 10px 0;"><b>Gesendet:</b> Mittwoch, 24. Februar 2021 um 20:08 Uhr<br/>
<b>Von:</b> "via cfe-dev" <cfe-dev@lists.llvm.org><br/>
<b>An:</b> cfe-dev@lists.llvm.org<br/>
<b>Betreff:</b> cfe-dev Digest, Vol 164, Issue 76</div>
<div name="quoted-content">Send cfe-dev mailing list submissions to<br/>
cfe-dev@lists.llvm.org<br/>
<br/>
To subscribe or unsubscribe via the World Wide Web, visit<br/>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br/>
or, via email, send a message with subject or body 'help' to<br/>
cfe-dev-request@lists.llvm.org<br/>
<br/>
You can reach the person managing the list at<br/>
cfe-dev-owner@lists.llvm.org<br/>
<br/>
When replying, please edit your Subject line so it is more specific<br/>
than "Re: Contents of cfe-dev digest..."<br/>
<br/>
<br/>
Today's Topics:<br/>
<br/>
1. Re: Inconsistent warnings with -Wundefined-reinterpret-cast<br/>
(Michael Laß via cfe-dev)<br/>
2. Create a batch to call Clang (shirley breuer via cfe-dev)<br/>
3. Re: Create a batch to call Clang (David Blaikie via cfe-dev)<br/>
4. Re: __attribute__((retain)) && llvm.used/llvm.compiler.used<br/>
(David Blaikie via cfe-dev)<br/>
5. Re: __attribute__((retain)) && llvm.used/llvm.compiler.used<br/>
(Fāng-ruì Sòng via cfe-dev)<br/>
<br/>
<br/>
----------------------------------------------------------------------<br/>
<br/>
Message: 1<br/>
Date: Wed, 24 Feb 2021 13:30:14 +0100<br/>
From: Michael Laß via cfe-dev <cfe-dev@lists.llvm.org><br/>
To: cfe-dev@lists.llvm.org<br/>
Subject: Re: [cfe-dev] Inconsistent warnings with<br/>
-Wundefined-reinterpret-cast<br/>
Message-ID: <3ED96E46-CD31-4BF3-89C2-8329E7C01B4A@bi-co.net><br/>
Content-Type: text/plain; charset=utf-8<br/>
<br/>
OK, I think I can answer my own question. Here is the current code of the undefined-reinterpret-cast check:<br/>
<br/>
<a href="https://github.com/llvm/llvm-project/blob/b94c215592bdba915455895b2041398dfb2ac44a/clang/lib/Sema/SemaCast.cpp#L1874" target="_blank">https://github.com/llvm/llvm-project/blob/b94c215592bdba915455895b2041398dfb2ac44a/clang/lib/Sema/SemaCast.cpp#L1874</a><br/>
<br/>
In the comment it states:<br/>
<br/>
// The cases that is checked for is:<br/>
// *reinterpret_cast<T*>(&a)<br/>
// reinterpret_cast<T&>(a)<br/>
// where accessing 'a' as type 'T' will result in undefined behavior.<br/>
<br/>
So casting a pointer and dereferencing it at some later point in time is not covered by the check. It can also miss cases like the following:<br/>
<br/>
int matrix[2 * 2] = {0, 1, 2, 3};<br/>
<br/>
// missed because matrix is not referenced:<br/>
int(&m1)[2][2] = *reinterpret_cast<int(*)[2][2]>(matrix);<br/>
<br/>
// missed because casted pointer is dereferenced via indexing operator:<br/>
int(&m2)[2][2] = reinterpret_cast<int(*)[2][2]>(&matrix)[0];<br/>
<br/>
On the question whether these casts (and dereferencing the resulting pointers) actually cause undefined behavior, I noticed a comment by Davis Herring on <a href="https://stackoverflow.com/a/15284276" target="_blank">https://stackoverflow.com/a/15284276</a>. I read it as: This is undefined behavior because the array referenced by the casted pointer does not actually exist and therefore the argument about array-to-pointer conversion made by the author of that post does not hold.<br/>
<br/>
Cheers,<br/>
Michael<br/>
<br/>
> Am 22.02.2021 um 21:01 schrieb Michael Laß via cfe-dev <cfe-dev@lists.llvm.org>:<br/>
><br/>
> Hi all!<br/>
><br/>
> I stumbled across some C++ code today that uses reinterpret_cast to reshape a 1D array into a 2D array. I wondered if this is actually legal or if it would cause undefined behavior. There is an elaborate post on Stack Overflow [1] that argues in favor of this method, quoting sections of the C++ standard but other people disagree [2].<br/>
><br/>
> So I went ahead and tested different variants of such conversions with Clang’s -Wundefined-reinterpret-cast flag:<br/>
><br/>
> <a href="https://godbolt.org/z/aE4fEM" target="_blank">https://godbolt.org/z/aE4fEM</a><br/>
><br/>
> The results can be summarized as:<br/>
> 1. Casting from int[4] to int(&)[2][2] or int(&)[][2] causes a warning<br/>
> 2. Casting from int(*)[4] to int(*)[2][2] or int(*)[][2] and _immediately_ dereferencing causes a warning<br/>
> 3. Casting from int(*)[4] to int(*)[2][2] or int(*)[][2] without immediate dereferencing seems fine<br/>
> 4. Casting from int[4] to int(*)[2] seems fine<br/>
> 5. Dereferencing those pointers from 3. and 4. afterwards also seems fine<br/>
><br/>
> This seems to be a bit inconsistent. From the results I assume that the cast itself is fine but dereferencing the casted pointer is undefined behavior. However, if those operations are split across multiple source code lines, there is no warning. Is this a bug or a natural limitation of the error checking within Clang?<br/>
><br/>
> Cheers,<br/>
> Michael<br/>
><br/>
><br/>
> [1] <a href="https://stackoverflow.com/a/15284276" target="_blank">https://stackoverflow.com/a/15284276</a><br/>
> [2] <a href="https://stackoverflow.com/q/44398700" target="_blank">https://stackoverflow.com/q/44398700</a><br/>
> _______________________________________________<br/>
> cfe-dev mailing list<br/>
> cfe-dev@lists.llvm.org<br/>
> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br/>
<br/>
<br/>
<br/>
------------------------------<br/>
<br/>
Message: 2<br/>
Date: Wed, 24 Feb 2021 14:07:08 +0100<br/>
From: shirley breuer via cfe-dev <cfe-dev@lists.llvm.org><br/>
To: cfe-dev@lists.llvm.org<br/>
Subject: [cfe-dev] Create a batch to call Clang<br/>
Message-ID:<br/>
<trinity-7e06f687-d452-495e-8ee8-1ac2f784053f-1614172028102@3c-app-gmx-bap71><br/>
<br/>
Content-Type: text/plain; charset="utf-8"<br/>
<br/>
An HTML attachment was scrubbed...<br/>
URL: <<a href="http://lists.llvm.org/pipermail/cfe-dev/attachments/20210224/29b3a344/attachment-0001.html" target="_blank">http://lists.llvm.org/pipermail/cfe-dev/attachments/20210224/29b3a344/attachment-0001.html</a>><br/>
<br/>
------------------------------<br/>
<br/>
Message: 3<br/>
Date: Wed, 24 Feb 2021 10:31:37 -0800<br/>
From: David Blaikie via cfe-dev <cfe-dev@lists.llvm.org><br/>
To: shirley breuer <shirley.breuer@gmx.de><br/>
Cc: Clang Dev <cfe-dev@lists.llvm.org><br/>
Subject: Re: [cfe-dev] Create a batch to call Clang<br/>
Message-ID:<br/>
<CAENS6EsLMnt+1x3zdL0p_BYEQDX35NwbrEU=w6DRengmuqAyAA@mail.gmail.com><br/>
Content-Type: text/plain; charset="utf-8"<br/>
<br/>
You mean something like a shell or Windows .bat script to run clang-format?<br/>
Yes, that should be possible - I'm not sure what you want that script to<br/>
do, though. clang-format can be run on main.c directly without the need for<br/>
an intermediate script, I'd have thought.<br/>
<br/>
On Wed, Feb 24, 2021 at 5:07 AM shirley breuer via cfe-dev <<br/>
cfe-dev@lists.llvm.org> wrote:<br/>
<br/>
> Hi Team,<br/>
><br/>
> I want to create a batch that calls and uses the Clang program to format<br/>
> my main.c file for example.<br/>
><br/>
> This should be done in tools like:<br/>
><br/>
> - TI (Texas Instruments Code Composer)<br/>
> - Eclipse IDE<br/>
> - ARM Keil<br/>
><br/>
> Is this possible and if so how?<br/>
><br/>
> I am new in this field and therefore quite inexperienced, also with the<br/>
> creation of a batch.<br/>
><br/>
><br/>
> Thanks a lot for your help!<br/>
><br/>
> Best regards<br/>
> Shirley<br/>
> _______________________________________________<br/>
> cfe-dev mailing list<br/>
> cfe-dev@lists.llvm.org<br/>
> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br/>
><br/>
-------------- next part --------------<br/>
An HTML attachment was scrubbed...<br/>
URL: <<a href="http://lists.llvm.org/pipermail/cfe-dev/attachments/20210224/a0739d26/attachment-0001.html" target="_blank">http://lists.llvm.org/pipermail/cfe-dev/attachments/20210224/a0739d26/attachment-0001.html</a>><br/>
<br/>
------------------------------<br/>
<br/>
Message: 4<br/>
Date: Wed, 24 Feb 2021 10:39:49 -0800<br/>
From: David Blaikie via cfe-dev <cfe-dev@lists.llvm.org><br/>
To: Fāng-ruì Sòng <maskray@google.com>, John McCall<br/>
<rjmccall@apple.com>, Eric Christopher <echristo@gmail.com><br/>
Cc: LLVM Developers Mailing List <llvm-dev@lists.llvm.org>, cfe-dev<br/>
<cfe-dev@lists.llvm.org><br/>
Subject: Re: [cfe-dev] __attribute__((retain)) &&<br/>
llvm.used/llvm.compiler.used<br/>
Message-ID:<br/>
<CAENS6Esmtn2bkUNXUzJEhRoXhZnK_tKT1wb7MHE8FXgSLsc_eg@mail.gmail.com><br/>
Content-Type: text/plain; charset="utf-8"<br/>
<br/>
(best to include folks from previous conversations in threads - sometimes<br/>
we can't all keep up to date with all the threads happening - so I've added<br/>
John McCall here, and echristo since he might have some thoughts on this<br/>
too)<br/>
<br/>
I'd lean towards (1) too myself - give the LLVM constructs consistent<br/>
semantics, and deal with the platform differences in the frontend during<br/>
the mapping down to LLVM.<br/>
<br/>
On Wed, Feb 24, 2021 at 1:09 AM Fāng-ruì Sòng via cfe-dev <<br/>
cfe-dev@lists.llvm.org> wrote:<br/>
<br/>
> On 2021-02-24, Fāng-ruì Sòng wrote:<br/>
> >Currently __attribute__((used)) lowers to llvm.used.<br/>
> ><br/>
> >* On Mach-O, a GlobalObject in llvm.used gets the S_ATTR_NO_DEAD_STRIP<br/>
> >attribute, which prevents linker GC (dead stripping).<br/>
> >* On COFF, a non-local-linkage GlobalObject[1] in llvm.used gets the<br/>
> >/INCLUDE: linker option (similar to ELF `ld -u`), which prevents<br/>
> >linker GC.<br/>
> > It should be possible to work with local linkage GlobalObject's as<br/>
> >well but that will require a complex COMDAT dance.<br/>
> >* On ELF, a global object llvm.used can be discarded by<br/>
> >ld.bfd/gold/ld.lld --gc-sections.<br/>
> > (If the section is a C identifier name, __start_/__stop_ relocations<br/>
> >from a live input section can retain the section, even if its defined<br/>
> >symbols are not referenced. [2] .<br/>
> > I understand that some folks use `__attribute__((used,<br/>
> >section("C_ident")))` and expect the sections to be similar to GC<br/>
> >roots, however,<br/>
> > non-C-identifier cases are very common, too. They don't get<br/>
> >__start_/__stop_ linker magic and the sections can always be GCed.<br/>
> > )<br/>
> ><br/>
> >In LangRef, the description of llvm.used contains:<br/>
> ><br/>
> >> If a symbol appears in the @llvm.used list, then the compiler,<br/>
> assembler, and **linker** are required to treat the symbol as if there is a<br/>
> reference to the symbol that it cannot see (which is why they have to be<br/>
> named). For example, if a variable has internal linkage and no references<br/>
> other than that from the @llvm.used list, it cannot be deleted. This is<br/>
> commonly used to represent references from inline asms and other things the<br/>
> compiler cannot “see”, and corresponds to “attribute((used))” in GNU C.<br/>
> ><br/>
> >Note that the "linker" part does not match the reality on ELF targets.<br/>
> >It does match the reality on Mach-O and partially on COFF.<br/>
> ><br/>
> >llvm.compiler.used:<br/>
> ><br/>
> >> The @llvm.compiler.used directive is the same as the @llvm.used<br/>
> directive, except that it only prevents the compiler from touching the<br/>
> symbol. On targets that support it, this allows an **intelligent linker to<br/>
> optimize references to the symbol without being impeded** as it would be by<br/>
> @llvm.used.<br/>
> ><br/>
> >Note that this explicitly mentions linker GC, so this appears to be<br/>
> >the closest thing to __attribute__((used)) on ELF.<br/>
> >However, LangRef also says:<br/>
> ><br/>
> >> This is a rare construct that should only be used in rare<br/>
> circumstances, and should not be exposed to source languages.<br/>
> ><br/>
> ><br/>
> ><br/>
> >My goal is to implement __attribute__((retain)) (which will be in GCC<br/>
> >11) on ELF. GCC folks think that 'used' and 'retain are orthogonal.<br/>
> >(see <a href="https://reviews.llvm.org/D96838#2578127" target="_blank">https://reviews.llvm.org/D96838#2578127</a>)<br/>
> ><br/>
> >Shall we<br/>
> ><br/>
> >1. Lift the source language restriction on llvm.compiler.used and<br/>
> >change __attribute__((used)) to use llvm.compiler.used on ELF.<br/>
><br/>
> It is too late here and I did not think of it clearly;-)<br/>
><br/>
> Clarify:<br/>
><br/>
> 1. Lift the source language restriction on llvm.compiler.used, let<br/>
> llvm.used use SHF_GNU_RETAIN on ELF, and change __attribute__((used)) to<br/>
> use llvm.compiler.used on ELF.<br/>
><br/>
><br/>
> __attribute__((retain)) has semantics which are not described by<br/>
> llvm.used/llvm.compiler.used. To facilitate linker GC,<br/>
> __attribute__((retain))<br/>
> causes the section to be placed in a unique section. The separate section<br/>
> behavior can be undesired in some cases (e.g. poorly written Linux kernel<br/>
> linker<br/>
> scripts which expect one section per name).<br/>
><br/>
> So in the -fno-function-sections -fno-data-sections case, a retained<br/>
> function/variable does not cause the whole .text/.data/.rodata to be<br/>
> retained.<br/>
><br/>
> The test llvm/test/CodeGen/X86/elf-retain.ll in<br/>
> <a href="https://reviews.llvm.org/D96837" target="_blank">https://reviews.llvm.org/D96837</a><br/>
> demonstrates the behavior. So I am not particularly clear that we should<br/>
> use<br/>
> llvm.compiler.used/llvm.used to describe __attribute__((retain)) .<br/>
><br/>
> >2. Or add a metadata (like <a href="https://reviews.llvm.org/D96837" target="_blank">https://reviews.llvm.org/D96837</a>)?<br/>
> ><br/>
> ><br/>
> >I lean to option 1 to leverage the existing mechanism.<br/>
> >The downside is that clang codegen will have some target inconsistency<br/>
> >(llvm.compiler.used on ELF while llvm.used on others).<br/>
> ><br/>
> ><br/>
> ><br/>
> >[1]: The implementation additionally allows GlobalAlias.<br/>
> >[2]: See<br/>
> <a href="https://maskray.me/blog/2021-01-31-metadata-sections-comdat-and-shf-link-order" target="_blank">https://maskray.me/blog/2021-01-31-metadata-sections-comdat-and-shf-link-order</a><br/>
> >"C identifier name sections" for details.<br/>
> _______________________________________________<br/>
> cfe-dev mailing list<br/>
> cfe-dev@lists.llvm.org<br/>
> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br/>
><br/>
-------------- next part --------------<br/>
An HTML attachment was scrubbed...<br/>
URL: <<a href="http://lists.llvm.org/pipermail/cfe-dev/attachments/20210224/699a5d73/attachment-0001.html" target="_blank">http://lists.llvm.org/pipermail/cfe-dev/attachments/20210224/699a5d73/attachment-0001.html</a>><br/>
<br/>
------------------------------<br/>
<br/>
Message: 5<br/>
Date: Wed, 24 Feb 2021 11:03:22 -0800<br/>
From: Fāng-ruì Sòng via cfe-dev <cfe-dev@lists.llvm.org><br/>
To: David Blaikie <dblaikie@gmail.com><br/>
Cc: LLVM Developers Mailing List <llvm-dev@lists.llvm.org>, cfe-dev<br/>
<cfe-dev@lists.llvm.org><br/>
Subject: Re: [cfe-dev] __attribute__((retain)) &&<br/>
llvm.used/llvm.compiler.used<br/>
Message-ID:<br/>
<CAFP8O3JTQSfB1Od9_rQXvasqbeXLTxOJoziy8Ln-595dDLFvKQ@mail.gmail.com><br/>
Content-Type: text/plain; charset="UTF-8"<br/>
<br/>
On Wed, Feb 24, 2021 at 10:40 AM David Blaikie <dblaikie@gmail.com> wrote:<br/>
><br/>
> (best to include folks from previous conversations in threads - sometimes we can't all keep up to date with all the threads happening - so I've added John McCall here, and echristo since he might have some thoughts on this too)<br/>
><br/>
> I'd lean towards (1) too myself - give the LLVM constructs consistent semantics, and deal with the platform differences in the frontend during the mapping down to LLVM.<br/>
<br/>
I chatted with Saleem Abdulrasool, who is in favor of (1), too.<br/>
<br/>
I am going to send these patches:<br/>
<br/>
(a) Add CodeGenModule::addUsedOrCompilerUsedGlobal (which uses<br/>
llvm.compiler.used for ELF and llvm.used for the others). Migrate some<br/>
addUsedGlobal call sites to use addUsedOrCompilerUsedGlobal.<br/>
(b) Add __attribute__((retain))<br/>
(c) Change llvm.used to use SHF_GNU_RETAIN if integrated assembler or<br/>
binutils>=2.36<br/>
<br/>
Currently llvm.used/llvm.compiler.used should have no difference on<br/>
ELF, so (a) & (b) do not affect users who don't use 'retain'.<br/>
<br/>
(c) will change the binary format representation of llvm.used, so<br/>
there is some risk if the consumer is not prepared for multiple<br/>
sections of the same name (which means they already break with<br/>
-fno-unique-section-names, but the option is rare).<br/>
On very large C/C++ projects, llvm.used has usually 0 or 1 element.<br/>
ObjC can have multiple llvm.used but that should work. So if there is<br/>
risk, the risk for other frontends.<br/>
I don't see a way to avoid that, but they can switch to llvm.compiler.used.<br/>
<br/>
Non-ELF users should not observe anything different.<br/>
<br/>
> On Wed, Feb 24, 2021 at 1:09 AM Fāng-ruì Sòng via cfe-dev <cfe-dev@lists.llvm.org> wrote:<br/>
>><br/>
>> On 2021-02-24, Fāng-ruì Sòng wrote:<br/>
>> >Currently __attribute__((used)) lowers to llvm.used.<br/>
>> ><br/>
>> >* On Mach-O, a GlobalObject in llvm.used gets the S_ATTR_NO_DEAD_STRIP<br/>
>> >attribute, which prevents linker GC (dead stripping).<br/>
>> >* On COFF, a non-local-linkage GlobalObject[1] in llvm.used gets the<br/>
>> >/INCLUDE: linker option (similar to ELF `ld -u`), which prevents<br/>
>> >linker GC.<br/>
>> > It should be possible to work with local linkage GlobalObject's as<br/>
>> >well but that will require a complex COMDAT dance.<br/>
>> >* On ELF, a global object llvm.used can be discarded by<br/>
>> >ld.bfd/gold/ld.lld --gc-sections.<br/>
>> > (If the section is a C identifier name, __start_/__stop_ relocations<br/>
>> >from a live input section can retain the section, even if its defined<br/>
>> >symbols are not referenced. [2] .<br/>
>> > I understand that some folks use `__attribute__((used,<br/>
>> >section("C_ident")))` and expect the sections to be similar to GC<br/>
>> >roots, however,<br/>
>> > non-C-identifier cases are very common, too. They don't get<br/>
>> >__start_/__stop_ linker magic and the sections can always be GCed.<br/>
>> > )<br/>
>> ><br/>
>> >In LangRef, the description of llvm.used contains:<br/>
>> ><br/>
>> >> If a symbol appears in the @llvm.used list, then the compiler, assembler, and **linker** are required to treat the symbol as if there is a reference to the symbol that it cannot see (which is why they have to be named). For example, if a variable has internal linkage and no references other than that from the @llvm.used list, it cannot be deleted. This is commonly used to represent references from inline asms and other things the compiler cannot “see”, and corresponds to “attribute((used))” in GNU C.<br/>
>> ><br/>
>> >Note that the "linker" part does not match the reality on ELF targets.<br/>
>> >It does match the reality on Mach-O and partially on COFF.<br/>
>> ><br/>
>> >llvm.compiler.used:<br/>
>> ><br/>
>> >> The @llvm.compiler.used directive is the same as the @llvm.used directive, except that it only prevents the compiler from touching the symbol. On targets that support it, this allows an **intelligent linker to optimize references to the symbol without being impeded** as it would be by @llvm.used.<br/>
>> ><br/>
>> >Note that this explicitly mentions linker GC, so this appears to be<br/>
>> >the closest thing to __attribute__((used)) on ELF.<br/>
>> >However, LangRef also says:<br/>
>> ><br/>
>> >> This is a rare construct that should only be used in rare circumstances, and should not be exposed to source languages.<br/>
>> ><br/>
>> ><br/>
>> ><br/>
>> >My goal is to implement __attribute__((retain)) (which will be in GCC<br/>
>> >11) on ELF. GCC folks think that 'used' and 'retain are orthogonal.<br/>
>> >(see <a href="https://reviews.llvm.org/D96838#2578127" target="_blank">https://reviews.llvm.org/D96838#2578127</a>)<br/>
>> ><br/>
>> >Shall we<br/>
>> ><br/>
>> >1. Lift the source language restriction on llvm.compiler.used and<br/>
>> >change __attribute__((used)) to use llvm.compiler.used on ELF.<br/>
>><br/>
>> It is too late here and I did not think of it clearly;-)<br/>
>><br/>
>> Clarify:<br/>
>><br/>
>> 1. Lift the source language restriction on llvm.compiler.used, let llvm.used use SHF_GNU_RETAIN on ELF, and change __attribute__((used)) to use llvm.compiler.used on ELF.<br/>
>><br/>
>><br/>
>> __attribute__((retain)) has semantics which are not described by<br/>
>> llvm.used/llvm.compiler.used. To facilitate linker GC, __attribute__((retain))<br/>
>> causes the section to be placed in a unique section. The separate section<br/>
>> behavior can be undesired in some cases (e.g. poorly written Linux kernel linker<br/>
>> scripts which expect one section per name).<br/>
>><br/>
>> So in the -fno-function-sections -fno-data-sections case, a retained<br/>
>> function/variable does not cause the whole .text/.data/.rodata to be retained.<br/>
>><br/>
>> The test llvm/test/CodeGen/X86/elf-retain.ll in <a href="https://reviews.llvm.org/D96837" target="_blank">https://reviews.llvm.org/D96837</a><br/>
>> demonstrates the behavior. So I am not particularly clear that we should use<br/>
>> llvm.compiler.used/llvm.used to describe __attribute__((retain)) .<br/>
>><br/>
>> >2. Or add a metadata (like <a href="https://reviews.llvm.org/D96837" target="_blank">https://reviews.llvm.org/D96837</a>)?<br/>
>> ><br/>
>> ><br/>
>> >I lean to option 1 to leverage the existing mechanism.<br/>
>> >The downside is that clang codegen will have some target inconsistency<br/>
>> >(llvm.compiler.used on ELF while llvm.used on others).<br/>
>> ><br/>
>> ><br/>
>> ><br/>
>> >[1]: The implementation additionally allows GlobalAlias.<br/>
>> >[2]: See <a href="https://maskray.me/blog/2021-01-31-metadata-sections-comdat-and-shf-link-order" target="_blank">https://maskray.me/blog/2021-01-31-metadata-sections-comdat-and-shf-link-order</a><br/>
>> >"C identifier name sections" for details.<br/>
>> _______________________________________________<br/>
>> cfe-dev mailing list<br/>
>> cfe-dev@lists.llvm.org<br/>
>> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br/>
<br/>
<br/>
<br/>
--<br/>
宋方睿<br/>
<br/>
<br/>
------------------------------<br/>
<br/>
Subject: Digest Footer<br/>
<br/>
_______________________________________________<br/>
cfe-dev mailing list<br/>
cfe-dev@lists.llvm.org<br/>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br/>
<br/>
<br/>
------------------------------<br/>
<br/>
End of cfe-dev Digest, Vol 164, Issue 76<br/>
****************************************</div>
</div>
</div>
</div></div></body></html>