<div dir="ltr">Removed the extra library in <a href="https://reviews.llvm.org/D95907">https://reviews.llvm.org/D95907</a>. Should it be cherry-picked into 12.x?</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Feb 2, 2021 at 3:10 PM <<a href="mailto:Yuanfang.Chen@sony.com">Yuanfang.Chen@sony.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> In hindsight, perhaps adding it to llvm/lib/Transforms/Scalar would be cleaner and would still properly show how to write an in-tree pass. I can go ahead and do that if you'd like.<br>
<br>
Agreed.<br>
<br>
________________________________________<br>
From: llvm-dev <<a href="mailto:llvm-dev-bounces@lists.llvm.org" target="_blank">llvm-dev-bounces@lists.llvm.org</a>> on behalf of Arthur Eubanks via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>><br>
Sent: Tuesday, February 2, 2021 2:41 PM<br>
To: <a href="mailto:tstellar@redhat.com" target="_blank">tstellar@redhat.com</a><br>
Cc: llvm-dev<br>
Subject: Re: [llvm-dev] HelloWorldPass ?<br>
<br>
This was added in <a href="https://reviews.llvm.org/D86979" rel="noreferrer" target="_blank">https://reviews.llvm.org/D86979</a><<a href="https://urldefense.com/v3/__https://reviews.llvm.org/D86979__;!!JmoZiZGBv3RvKRSx!uvevl9WxJWZajB0Ry7OvTsTpBbInzuVMLFel-NpaLf8cgfknTp5mrDkGD7s-BlN6ng$" rel="noreferrer" target="_blank">https://urldefense.com/v3/__https://reviews.llvm.org/D86979__;!!JmoZiZGBv3RvKRSx!uvevl9WxJWZajB0Ry7OvTsTpBbInzuVMLFel-NpaLf8cgfknTp5mrDkGD7s-BlN6ng$</a>>. My goal was to show how to write an in-tree NPM pass. It didn't really fit into any of the existing directories/libraries, so I created a similar one to the legacy HelloWorld example. Since it's unconditionally added to PassRegistry.def, I followed the CMake from something like llvm/lib/Transforms/Scalar. TBH I'm not super familiar with the various CMake machinery, so any suggestions are welcome.<br>
<br>
In hindsight, perhaps adding it to llvm/lib/Transforms/Scalar would be cleaner and would still properly show how to write an in-tree pass. I can go ahead and do that if you'd like.<br>
<br>
<br>
On Tue, Feb 2, 2021 at 2:32 PM Tom Stellard via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><mailto:<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>>> wrote:<br>
On 2/2/21 1:32 PM, via llvm-dev wrote:<br>
> My team is packaging up our next release, and this new pass popped<br>
> up.  It has its own library and everything (LLVMHelloWorld.lib),<br>
> but it appears to be mandatory when linking against LLVM in general.<br>
> I can see it's an example pass regarding the new pass manager, but<br>
> I can also see the equivalent example for the legacy pass manager<br>
> wasn't mandatory and we don't have it in our package.<br>
><br>
> It seems like kind of a trivial thing to worry about--it's clearly<br>
> harmless and doesn't take up a lot of space--but it's how the thing<br>
> is packaged differently than the old Hello pass that bothers me.<br>
><br>
> - I see it's listed in lib/Passes/Registry.def; the old one wasn't.<br>
><br>
> - I see its CMakeLists.txt uses add_llvm_component_library where the<br>
> old one uses add_llvm_library.<br>
><br>
<br>
Arthur, was the use of add_llvm_component_library() here intentional?<br>
<br>
-Tom<br>
<br>
> I can't say I understand these things but just being different<br>
> raises my eyebrow.  Is there a good reason they're different?<br>
> And just for my own curiosity, what's the simplest way to avoid<br>
> needing it in our package?<br>
><br>
> Thanks,<br>
> --paulr<br>
><br>
> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><mailto:<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>><br>
> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><<a href="https://urldefense.com/v3/__https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev__;!!JmoZiZGBv3RvKRSx!uvevl9WxJWZajB0Ry7OvTsTpBbInzuVMLFel-NpaLf8cgfknTp5mrDkGD7v9MrAJRQ$" rel="noreferrer" target="_blank">https://urldefense.com/v3/__https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev__;!!JmoZiZGBv3RvKRSx!uvevl9WxJWZajB0Ry7OvTsTpBbInzuVMLFel-NpaLf8cgfknTp5mrDkGD7v9MrAJRQ$</a>><br>
><br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><mailto:<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><<a href="https://urldefense.com/v3/__https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev__;!!JmoZiZGBv3RvKRSx!uvevl9WxJWZajB0Ry7OvTsTpBbInzuVMLFel-NpaLf8cgfknTp5mrDkGD7v9MrAJRQ$" rel="noreferrer" target="_blank">https://urldefense.com/v3/__https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev__;!!JmoZiZGBv3RvKRSx!uvevl9WxJWZajB0Ry7OvTsTpBbInzuVMLFel-NpaLf8cgfknTp5mrDkGD7v9MrAJRQ$</a>><br>
</blockquote></div>