[llvm-dev] HelloWorldPass ?

via llvm-dev llvm-dev at lists.llvm.org
Thu Feb 4 07:34:17 PST 2021


It would be nice to see this in 12.x, but not critical.  That said, the patch looks straightforward enough to go in without a problem, so it’s up to the code owners/release manager.
--paulr

From: Arthur Eubanks <aeubanks at google.com>
Sent: Wednesday, February 3, 2021 4:15 PM
To: llvm-dev <llvm-dev at lists.llvm.org>; Robinson, Paul <paul.robinson at sony.com>; tstellar at redhat.com
Subject: Re: [llvm-dev] HelloWorldPass ?

Removed the extra library in https://reviews.llvm.org/D95907<https://urldefense.com/v3/__https:/reviews.llvm.org/D95907__;!!JmoZiZGBv3RvKRSx!uzEZL6NwE-0FvPPfgLcNXU9WEUMH8UbNeY-w_q7jmVJrt3RRzq1IK44fmr5MhTXxgA$>. Should it be cherry-picked into 12.x?

On Tue, Feb 2, 2021 at 3:10 PM <Yuanfang.Chen at sony.com<mailto:Yuanfang.Chen at sony.com>> wrote:
> 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.

Agreed.

________________________________________
From: llvm-dev <llvm-dev-bounces at lists.llvm.org<mailto:llvm-dev-bounces at lists.llvm.org>> on behalf of Arthur Eubanks via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>>
Sent: Tuesday, February 2, 2021 2:41 PM
To: tstellar at redhat.com<mailto:tstellar at redhat.com>
Cc: llvm-dev
Subject: Re: [llvm-dev] HelloWorldPass ?

This was added in https://reviews.llvm.org/D86979<https://urldefense.com/v3/__https:/reviews.llvm.org/D86979__;!!JmoZiZGBv3RvKRSx!uzEZL6NwE-0FvPPfgLcNXU9WEUMH8UbNeY-w_q7jmVJrt3RRzq1IK44fmr71s9D4JA$><https://urldefense.com/v3/__https://reviews.llvm.org/D86979__;!!JmoZiZGBv3RvKRSx!uvevl9WxJWZajB0Ry7OvTsTpBbInzuVMLFel-NpaLf8cgfknTp5mrDkGD7s-BlN6ng$<https://urldefense.com/v3/__https:/reviews.llvm.org/D86979__;!!JmoZiZGBv3RvKRSx!uvevl9WxJWZajB0Ry7OvTsTpBbInzuVMLFel-NpaLf8cgfknTp5mrDkGD7s-BlN6ng$>>. 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.

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.


On Tue, Feb 2, 2021 at 2:32 PM Tom Stellard via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org><mailto:llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>>> wrote:
On 2/2/21 1:32 PM, via llvm-dev wrote:
> My team is packaging up our next release, and this new pass popped
> up.  It has its own library and everything (LLVMHelloWorld.lib),
> but it appears to be mandatory when linking against LLVM in general.
> I can see it's an example pass regarding the new pass manager, but
> I can also see the equivalent example for the legacy pass manager
> wasn't mandatory and we don't have it in our package.
>
> It seems like kind of a trivial thing to worry about--it's clearly
> harmless and doesn't take up a lot of space--but it's how the thing
> is packaged differently than the old Hello pass that bothers me.
>
> - I see it's listed in lib/Passes/Registry.def; the old one wasn't.
>
> - I see its CMakeLists.txt uses add_llvm_component_library where the
> old one uses add_llvm_library.
>

Arthur, was the use of add_llvm_component_library() here intentional?

-Tom

> I can't say I understand these things but just being different
> raises my eyebrow.  Is there a good reason they're different?
> And just for my own curiosity, what's the simplest way to avoid
> needing it in our package?
>
> Thanks,
> --paulr
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org><mailto: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!uzEZL6NwE-0FvPPfgLcNXU9WEUMH8UbNeY-w_q7jmVJrt3RRzq1IK44fmr6Ny8ZYwA$><https://urldefense.com/v3/__https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev__;!!JmoZiZGBv3RvKRSx!uvevl9WxJWZajB0Ry7OvTsTpBbInzuVMLFel-NpaLf8cgfknTp5mrDkGD7v9MrAJRQ$<https://urldefense.com/v3/__https:/lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev__;!!JmoZiZGBv3RvKRSx!uvevl9WxJWZajB0Ry7OvTsTpBbInzuVMLFel-NpaLf8cgfknTp5mrDkGD7v9MrAJRQ$>>
>

_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org><mailto: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!uzEZL6NwE-0FvPPfgLcNXU9WEUMH8UbNeY-w_q7jmVJrt3RRzq1IK44fmr6Ny8ZYwA$><https://urldefense.com/v3/__https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev__;!!JmoZiZGBv3RvKRSx!uvevl9WxJWZajB0Ry7OvTsTpBbInzuVMLFel-NpaLf8cgfknTp5mrDkGD7v9MrAJRQ$<https://urldefense.com/v3/__https:/lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev__;!!JmoZiZGBv3RvKRSx!uvevl9WxJWZajB0Ry7OvTsTpBbInzuVMLFel-NpaLf8cgfknTp5mrDkGD7v9MrAJRQ$>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210204/6b911514/attachment.html>


More information about the llvm-dev mailing list