similar to: right way for setting PreserveLCSSA with new pass manager

James, we are using an *unmodified* llvm-project (master llorg), and just add some extra projects from our internal repos to the top-level. Thanks, Slava From: James Y Knight [mailto:jyknight at google.com] Sent: Wednesday, July 17, 2019 11:19 AM To: Zakharin, Vyacheslav P <vyacheslav.p.zakharin at intel.com> Cc: llvm-dev <llvm-dev at lists.llvm.org> Subject: Re: [llvm-dev] [RFC]

Hi Cameron, Thank you for the comments, but I am confused even more now ☺ > llvm.rint won't honor the FPEnv in all cases. It falls under the default FPEnv The default FPEnv section specifies round-to-nearest rounding mode. In this case, how is it correct to map rint() user call to llvm.rint intrinsic call? If this is just a temporary inconsistency, and the long term solution is to map

Hello, I wrote my own pass which needs to do some loop unrolling. I can perform loop unrolling via opt: opt -mem2reg -loops -loop-simplify -loop-rotate -lcssa -loop-unroll -unroll-count=50 mytest.bc -o mytest.bc This command works perfectly. However, what I really want is to produce the **same behavior** but from my own pass (i.e., I don't want to use opt). I wrote a Module pass which

Hello, My team is using some non-llvm projects along with llvm-project monorepo. The projects are checked out to the top level of llvm-project, and 'git status' would complain about them unless we add them to .gitignore. We do not really want to change llorg's .gitignore on our side, so may we propose changing llorg's .gitignore to ignore all top-level files/directories that are

Hi, I'm writing a function pass which is dynamically loaded by opt and I need some analysis and passes to be run before my pass: virtual void getAnalysisUsage(AnalysisUsage &AU) const { AU.addRequired<LoopInfo>(); AU.addPreserved<LoopInfo>(); AU.addRequiredID(LoopSimplifyID); AU.addPreservedID(LoopSimplifyID);

Hello, I believe llvm.rint description in LangRef is not quite complete. Llvm seems to map math.h:rint() call to llvm.rint intrinsic, and the LangRef says that the result of llvm.rint matches the result of libm rint() call. Next, LangRef states that llvm.rint "returns the operand rounded to the nearest integer." Shouldn't the specification also say that "the actual rounding

Hello, I wrote my own pass which needs to do some loop unrolling. I can perform loop unrolling via opt: opt -mem2reg -loops -loop-simplify -loop-rotate -lcssa -loop-unroll -unroll-count=50 mytest.bc -o mytest.bc This command works perfectly. However, what I really want is to produce the **same behavior** but from my own pass (i.e., I don't want to use opt). I wrote a Module pass which

On Aug 6, 2012, at 6:04 AM, Jorge Navas <navas at comp.nus.edu.sg> wrote: > > Hello, > > I wrote my own pass which needs to do some loop unrolling. > > I can perform loop unrolling via opt: > > opt -mem2reg -loops -loop-simplify -loop-rotate -lcssa -loop-unroll > -unroll-count=50 mytest.bc -o mytest.bc > > This command works perfectly. > >

InstCombine says in its getAnalysisUsage that it preserves the CFG, but for the 4th argument in its INITIALIZE_PASS call, it says false, which I believe corresponds to whether it preserves the CFG. Is this a mistake, or is there deeper meaning here? InstructionCombining.cpp:73-82 char InstCombiner::ID = 0; INITIALIZE_PASS(InstCombiner, "instcombine", "Combine

Hi again, I come back to this issue with an example. It's a pass which does nothing but throw the 'Unable to schedule' error. namespace { struct MyPass : public FunctionPass { static char ID; // Pass identification, replacement for typeid MyPass() : FunctionPass(ID) { initializeMyPassPass(*PassRegistry::getPassRegistry()); } virtual void

On 8/7/19 6:20 PM, Hiroshi Yamauchi wrote: > I basically run "clang > -fexperimental-new-pass-manager -print-after-all ..." > > It's conceivable that something is different in our setup or in clang > (from opt)... I'll see if I can reproduce it outside our setup. Does it depend on machine architecture? I generally use x86... regards,   Fedor. > > Thanks.

Hi Michael, > InstCombine says in its getAnalysisUsage that it preserves the CFG, > but for the 4th argument in its INITIALIZE_PASS call, it says false, > which I believe corresponds to whether it preserves the CFG. that argument should be set to true if the pass only looks at the CFG, i.e. whatever it computes/does is only a function of the CFG, and doesn't otherwise depend on what

If someone can manage it, it wouldn't be a bad thing - obviously open up more parallelism (I don't know how much of LLVM can be built before you hit everything that needs tblgen run - I guess libSupport and some other bits) On Mon, Jul 1, 2019 at 12:54 PM Zakharin, Vyacheslav P via llvm-dev < llvm-dev at lists.llvm.org> wrote: > [resending to the whole list] > > > >

FWIW, tablegen does not update timestamps for .inc files, if their contents is unchanged, so if you somehow affect a .td file's timestamp (without changing its contents) it will trigger rebuild of the corresponding .inc file with all subsequent incremental make builds. At the same time, this will not trigger rebuilding any targets dependent on this .inc file, since it is not modified. From

Am Fr., 7. Feb. 2020 um 13:06 Uhr schrieb Chris Lattner <clattner at nondot.org >: > > Furthermore, my experience is that specialized IRs never get the > investment in (e.g.). testing, location propagation for debugging optimized > code, textual round tripping, pass management, and the multitude of other > things that are required for a world class compiler implementation.

Much of this has been discussed (over many, many years) on https://bugs.llvm.org/show_bug.cgi?id=28222 Some of the issues that were identified included: 1 - Poor tablegen dependency handling leading to unexpected rebuilds. 2 - Debug STL iterator checks taking an insane amount of time (might be MSVC specific). 3 - Lack of parallelization of custom commands (XCode and VS builds) - VS at least

Hi Philip, Thanks for the response. Under llvm-5.0.2 and llvm-6.0.1 in Debug mode, the crash hit at the same assertion: /usr/local/include/llvm/IR/PassManager.h:689: typename PassT::Result& llvm::AnalysisManager<IRUnitT, ExtraArgTs>::getResult(IRUnitT&, ExtraArgTs ...) [with PassT = llvm::InnerAnalysisManagerProxy<llvm::AnalysisManager<llvm::Loop,

This question has been submitted to stackoverflow (https://stackoverflow.com/questions/51934964/function-optimization-pass) but someone suggested me that it should be submitted to llvm-dev mailing list instead. I'm sorry for the duplication. I am trying to use PassBulider and FunctionPassManager || to optimize a function in a module, what I have done is: mod = ...load module from LLVM

On 2/5/20 6:13 PM, Chris Lattner via llvm-dev wrote: > > >> On Feb 2, 2020, at 10:35 PM, Michael Kruse via llvm-dev >> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >>> >>> That's actually not how I read it. Red/green trees was *one* of the >>> nine items you mentioned in your list and this didn't

Hi all, I'd like to be able to use TargetTransformInfo to make architecture specific code generation decisions from the XLA LLVM IR emitter[0]. However, we don't have a great way to do this today -- TargetTransformInfo is wrapped in a TargetIRAnalysis and getting the TargetTransformInfo out of it requires something like: FunctionAnalysisManager DummyFAM; TTI = TIRA.run(F, DummyFAM);