similar to: [LLVMdev] Why some registered passes are not available through opt?

Hi Duncan, Is it correct that opt does not understand codegen passes, but llc understands both analysis/transformation and codegen passes? I would like to modify bugpoint to work on this end. Thanks, - D. 2012/6/29 Duncan Sands <baldrick at free.fr>: > Hi Dima, > >> I'm trying to understand why opt tool does not know some of the >> registered passes, for example,

Hi Dmitry, > Is it correct that opt does not understand codegen passes, but llc > understands both analysis/transformation and codegen passes? no. Ciao, Duncan. I would > like to modify bugpoint to work on this end. > > Thanks, > - D. > > 2012/6/29 Duncan Sands <baldrick at free.fr>: >> Hi Dima, >> >>> I'm trying to understand why opt

Hi Dima, > I'm trying to understand why opt tool does not know some of the > registered passes, for example, -targetpassconfig, -gc-lowering, > -unreachableblockelim, -unreachableblockelim, -stack-protector, > -machinemoduleinfo. This prevents me from using bugpoint to reduce the > crash in backend. As I understand, they should be registered and > available through the

Sorry, then I don't understand. If I invoke backend with target->addPassesToEmitFile, it adds both opt and llc passes. Thus, PassManager contains both opt and llc passes after that. In case of crash, bugpoint reloads all passes from the failing pass manager to the separate instance of opt. If opt and llc both do not support such mixing, then I'm guessing I need to replace

Thanks again. I executed the following command line llc -O3 comb.ll.bc -debug-pass=Arguments and got Pass Arguments: -targetdata -targetpassconfig -no-aa -tbaa -targetlibinfo -basicaa -collector-metadata -machinemoduleinfo -machine-branch-prob -preverify -domtree -verify -loops -loop-simplify -scalar-evolution -loop-simplify -iv-users -loop-reduce -gc-lowering -unreachableblockelim

Hi, > I executed the following command line > > llc -O3 comb.ll.bc -debug-pass=Arguments > > and got > > Pass Arguments: -targetdata -targetpassconfig -no-aa -tbaa > -targetlibinfo -basicaa -collector-metadata -machinemoduleinfo > -machine-branch-prob -preverify -domtree -verify -loops -loop-simplify > -scalar-evolution -loop-simplify -iv-users -loop-reduce

Does LLVM have loop multiversioning ? it seems it does not with clang++ -O3 -mllvm -debug-pass=Arguments program.c -c bash-4.1$ clang++ -O3 -mllvm -debug-pass=Arguments fast_algorithms.c -c clang-3.6: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated Pass Arguments: -datalayout -notti -basictti -x86tti -targetlibinfo -no-aa -tbaa -scoped-noalias

Dear LLVM, The TargetData pass needs target data layout to be specified in constructor, and therefore its normal ctor is defined, but always gives a fatal error. Still, is there any way to make it loadable into the opt tool? I need this to make use of bugpoint in reducing backend test case. Thanks, - Dima.

On Sep 5, 2013, at 5:15 PM, Ken Dyck <kd at kendyck.com> wrote: > Hi, > > One of the long-standing code clean-up bugs in Bugzilla is to extract > the Machine* code from the CodeGen library into a separate one, on > which CodeGen depends ( > http://llvm.org/bugs/show_bug.cgi?id=1121). > > I'd like to start working on this. The general approach I'm planning

Hi, On 12/06/12 13:09, Abdul Wahid Memon wrote: > Thanks alot. How can we view those optimization which are enabled when we do > > llc -O3 comb.ll llc -O3 comb.ll -debug-pass=Arguments > > Are these the same as the ones produced by the following command line no, as I mentioned before they are of a completely different nature to the optimizations that opt does. Ciao, Duncan.

Hello, I am trying to replicate the output from opt -O3 foo.bc -o foo.opt.bc by specifying the individual passes instead of the -O3 flag. Looking at the passes from opt -O3 foo.bc -o foo.bc -debug-pass=Executions it seems there are two passes being run. When I run the flags indicated for the two passes specified in the 'Pass Arguments:' as two sequential opt processes or a single opt

Thanks alot. How can we view those optimization which are enabled when we do llc -O3 comb.ll Are these the same as the ones produced by the following command line llvm-as < /dev/null | opt -O3 -disable-output -debug-pass=Arguments Regards Shahzad On Tue, Jun 12, 2012 at 1:01 PM, Duncan Sands <baldrick at free.fr> wrote: >> Yes. But how exactly code generation (optimized one)

Hi, One of the long-standing code clean-up bugs in Bugzilla is to extract the Machine* code from the CodeGen library into a separate one, on which CodeGen depends ( http://llvm.org/bugs/show_bug.cgi?id=1121). I'd like to start working on this. The general approach I'm planning to take is: 1. Identify which code to move. 2. Eliminate all dependencies that the Machine code has on the

Dear LLVM, I'm trying to understand why the attached IR code works for x86_64 target and fails for nvptx64, because of unimplemented expand during the target lowering. Any ideas? Just change the target triple to x86_64-unknown-unknown, and the same IR code could we successfully codegen-ed for x86_64. Thanks, - Dima. dmikushin at dmikushin-desktop:~/Desktop$ gdb ~/sandbox/bin/llc GNU gdb

OK, thanks. For our project I implemented a similar workaround: extend each i1 memory item to i8 and load/store i1 to i8 with a type cast. Still, the issue in NVPTX remains. I don't know whether NVIDIA or community fellows have any reasonable priority to fix it (or at least put an NYI assertion!). It seems to be quite more complex, than implementing custom lowering handler, that's why

Okay, few issues here: First, i1 is used in the NVPTX back-end to map to the predicate (.pred) type. We definitely do not want to declare this type as illegal. The real issue is lack of complete support for this type. The PTX language places restrictions on what can be done with .pred registers, and it looks like the failure is here: kernelgen_hostcall.exit228: ; preds =

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

In our (NVIDIA's) NVVM IR spec, we define i1 having a memory size of 8 bit. setOperationAction(ISD::LOAD, MVT::i1, Custom); setOperationAction(ISD::STORE, MVT::i1, Custom); is the right way to go. Yuan From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Justin Holewinski Sent: Monday, July 02, 2012 9:55 AM To: Dmitry N. Mikushin Cc: llvmdev at

Hi, Is there a mechanism in place to use the new pass manager with target-specific passes added (at the moment) via addIRPasses in TargetPassConfig? I did see any code related to that, did I miss something? Is it in plan? -- Krzysztof Parzyszek kparzysz at quicinc.com AI tools development

Hi Evan, >>Is it possible to implement it without using MachineModuleInfo? but llvm-2.5 didn't , if implement it without using MachineModuleInfo, so I should create another ADT, but that is mostly same to MachineModuleInfo, that's repeat work! or less cost for me ! >> It's being removed. if so, what's the replacement of the MachineModuleInfo ? zhangzw