similar to: Switching to the New Pass Manager by Default

I think so far most individual projects have their own statistics on build time/performance impact on switching to the new PM, but I agree that there should at least be one place that people can reference on the impact. On Fri, Aug 2, 2019 at 1:14 PM Philip Reames <listmail at philipreames.com> wrote: > Thanks for all the hard work that went into getting it here. > > +1 > >

I believe a good amount of them (if not most of them) have already been ported! Off the top of my head, I remember that asan, tsan, msan, hwasan, the kernel santizers, and sancov have been ported. I don't think ubsan has been ported yet though. You can also check if other passes you need run under the new PM by checking PassRegistry.def. On Fri, Aug 2, 2019, 14:20 Jordan Rupprecht

> -----Original Message----- > From: Fāng-ruì Sòng <maskray at google.com> > Sent: Friday, August 21, 2020 4:04 PM > To: Eli Friedman <efriedma at quicinc.com> > Cc: Leonard Chan <leonardchan at google.com>; llvm-dev at lists.llvm.org > Subject: [EXT] Re: [llvm-dev] [RFC][LLVM] New Constant type for > representing function PLT entries > > On Fri, Aug

On Aug 24, 2020, at 6:47 PM, Leonard Chan via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Thanks for the responses! I’m going to see if I can summarize the concerns and ideas people have (for my own clarity) and see where we can go on from there. Folks seem to be on board with the idea of introducing some new IR entity that (after linking) *could* be a reference into the PLT, but some

Hello, I'm in the process of creating a pass for the new PM for SafeStack which is only available as a part of the legacy PM. The only thing bugging me is in regards to the TargetPassConfig analysis. Whereas most other passes/analyses I have seen separate the logic between the actual pass and anything it does to the IRUnits it runs over are in 2 separate classes, TargetPassConfig has them

Hi all, I'm attempting to move the AddressSanitizer pass from the legacy PassManager to the new one because the new one has various benefits over legacy and wanted to clarify on something. Does creating the static RegisterPass struct register the pass with the new PassManager? It seems that RegisterPass does the same things that the INITIALIZE_PASS_* macros do but it registers the pass with

Hi Leonard, Fedor, while it's true that RegisterPass is not applicable for new-pm passes, PassRegistry.def is not the whole story. Passes in PassRegistry are available for the opt tool. The sanitizers are passes that usually get added to the pipeline by the frontend. There, you need to use PassBuilder's callbacks mechanism to hook the sanitizer into the optimizer. Assuming you're

Error message is: Starting Mail Virus Scanner (amavisd): Digest::MD5 version 2.22 required--this is only version 2.20 at... Googled for Digest::MD5 and found v2.33 (http://search.cpan.org/~gaas/Digest-MD5-2.33/MD5.pm) Downloaded it untared it perl ./Makefile.PL ...error missing Digest::Base Download from CPAN perl ./Makefile.PL make make test make install Back to Digest::MD5 perl ./Makefile.PL

Frontends _are_ using PassBuilder, but they need to hook into the default pipeline creation to insert the sanitizer passes. On Tue, Sep 25, 2018 at 12:15 PM Fedor Sergeev <fedor.sergeev at azul.com> wrote: > Hmm... frontends should be using PassBuilder anyway. > And if they are using PassBuilder then they are using PassRegistry.def as > well - all the >

Is there a reason for why `-asan` and `-asan-module` can be mixed but Function passes and Module passes with the new PM can't be mixed? - Leo On Thu, Sep 27, 2018 at 3:21 AM Fedor Sergeev <fedor.sergeev at azul.com> wrote: > > On 09/27/2018 12:25 PM, Philip Pfaffe wrote: >> >> `opt < %s -passed='asan' -asan-module -S` > > asan-module is another

I made a second MachineFunctionPass that can run on new PM and made it similar to the MachineFunctionPass for legacy PM. It seemed that the only required analysis used by it was MachineModuleInfo which I also made a new PM analysis for by separating it into 2 classes: 1 that holds the meta information specific to a module, and 1 that's the pass which holds an instance to the first class. The

Hi all, I merged from the monorepo master this morning and ran all tests and noticed that llvm/test/tools/llvm-nm/libtool-response-file.test was failing due to running out of memory. The test in particular just runs `llvm-nm --help` and running this prints the help info followed by endless whitespace. Has anyone else ran into this? Thanks, Leonard

Hi all, I'm in the process of trying to port ShadowCallStack from the legacy pass manager to the new one. I ran into an issue though where it seems I cannot link against anything I added in ShadowCallStack.cpp when trying to build c-index-test (via just running ninja check-all). I think the reason for this is because nothing under lib/Target/X86/ is a part of any library compiled with

+cfe-dev at lists.llvm.org On Thu, Jan 10, 2019 at 2:16 PM Jacob Lifshay <programmerjake at gmail.com> wrote: > > Stash a lookup table from integers to strings in Context and dynamically allocate integers for new strings. You can then keep integers in most of the code, writing/displaying strings for the integers with an entry in the table when writing to files or displaying. > >

Hi all, We would like to propose a new Constant type in LLVM for representing entries in the Procedure Linkage Table (PLT). The PLT is a data structure used for dispatching position-independent function calls to appropriate functions where the address of the function is not known statically. Right now, if a call is made to a function, it may be lowered to a direct call to the function itself or

I do have concerns about the amount of object level modeling that we want to do in the IR though. While it isn't the highest level IR we've managed to mostly avoid these kinds of features/complications in the past. I'm definitely interested in hearing some alternate implementations here and there rather than a full set of constants for relocations. Keeping the IR abstract enough over

IIUC, the actual requirements for the proposed pltentry(@X) constant is: 1. The returned address MUST have a constant offset at link-time from some other unspecified but defined-in-the-same-binary/DSO symbol Y. Which symbol it is is presumed not to matter because all locally-defined symbols have constant offsets from each-other, anyhow. 2. The address is otherwise insignificant. (Therefore, coming

Hi, I wanted to see if there was a way in IR to emit a local alias such that I would get: ``` .type _ZTVSt13bad_exception, at object # @_ZTVSt13bad_exception .globl _ZTVSt13bad_exception _ZTVSt13bad_exception: *.L_ZTVSt13bad_exception:* .long 0 # 0x0 .long (_ZTISt13bad_exception.rtti_proxy-.L_ZTVSt13bad_exception)-8 .long

Just my two cents: Anyone thought of asking Red Hat to use documentation? I think they are getting much from the community so to copy public accessible documentation when permitted by RH could be an easy way. Why not giving that a try? Am 18. Januar 2015 20:56:59 MEZ, schrieb Darr247 <darr247 at gmail.com>: >On 18 January 2015 @19:07 zulu, Mark LaPierre wrote: >> good at C or C++

Given the following C++ code: ``` // test.cpp struct Foo { int public_foo(); int outside_foo(); [[gnu::always_inline]] int inline_foo() { int x = outside_foo(); if (x % 17) { x += 1; } return x; } [[gnu::noinline]] int inline_bar1() { int x = inline_foo(); if (x % 23) { x += 2; } return x; } [[gnu::noinline]] int inline_bar2() {