search for: parsecodegenarg

The option handling in clang in fairly different from opt. The comment about the mixed name was just a guess as to why you don't see the driver passing it down to -cc1. Once that is working, you will probably need to: * Patch ParseCodeGenArgs to record the option * Patch EmitAssemblyHelper::CreatePasses to set the option to enable the pass in the pass manager (assuming that is the effect you want). On 1 October 2013 15:48, Diego Novillo <dnovillo at google.com> wrote: > On Tue, Oct 1, 2013 at 3:42 PM, Rafael Espíndola >...

...ng it down to -cc1. Clang::ConstructJob is ~2k lines long. I was putting the handling of this option too far down. I moved it up and it's now being passed. Not sure what order needs to be kept in this function, however. > Once that is working, you will probably need to: > > * Patch ParseCodeGenArgs to record the option > * Patch EmitAssemblyHelper::CreatePasses to set the option to enable > the pass in the pass manager (assuming that is the effect you want). Thanks. That was my disconnect. I was confusing 'opt' with clang's backend. The attached patch does what I want....

On Tue, Oct 1, 2013 at 3:42 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > You are calling the option -auto-profile in some places and > -fauto-profile in others. Maybe it is just a typo? In opt, the option is named '-auto-profile' when I instantiate the pass: INITIALIZE_PASS(AutoProfile, "auto-profile", "Auto Profile loader", false,

...::ConstructJob is ~2k lines long. I was putting the handling of > this option too far down. I moved it up and it's now being passed. > Not sure what order needs to be kept in this function, however. > >> Once that is working, you will probably need to: >> >> * Patch ParseCodeGenArgs to record the option >> * Patch EmitAssemblyHelper::CreatePasses to set the option to enable >> the pass in the pass manager (assuming that is the effect you want). > > Thanks. That was my disconnect. I was confusing 'opt' with clang's backend. > > The attach...

On Fri, Nov 15, 2013 at 11:19 AM, Umesh Kalappa <umesh.kalappa0 at gmail.com> wrote: > Hi Aaron, > >>>Why is getLastArgIntValue being called twice in the first place? > > It has been called from the getOptimizationLevel() ,which in turn called by > methods like ParseCodeGenArgs() and ParseLangArgs(), > > where method getOptimizationLevel() register the "invalid integral value" > diagnostics in the diagnostics engine twice ,since it was called twice. > > So i added the flag to check if the diagnostics is already registered for a > specific argu...

...(only positive changes are reported). clang::Sema::CheckHexagonBuiltinCpu([snip]) [function] 170316 ProcessDeclAttribute([snip]) [function] 125893 llvm::AArch64InstPrinter::printAliasInstr([snip]) [function] 105133 llvm::AArch64AppleInstPrinter::printAliasInstr([snip]) [function] 105133 ParseCodeGenArgs([snip]) [function] 64692 unswitchNontrivialInvariants([snip]) [function] 40180 getAttrKind([snip]) [function] 35811 clang::DumpCompilerOptionsAction::ExecuteAction() [function] 32417 llvm::UpgradeIntrinsicCall([snip]) [function] 30239 bool llvm::InstructionSelector::executeMatchTable<...

...ported). > > clang::Sema::CheckHexagonBuiltinCpu([snip]) [function] 170316 > ProcessDeclAttribute([snip]) [function] 125893 > llvm::AArch64InstPrinter::printAliasInstr([snip]) [function] 105133 > llvm::AArch64AppleInstPrinter::printAliasInstr([snip]) [function] 105133 > ParseCodeGenArgs([snip]) [function] 64692 > unswitchNontrivialInvariants([snip]) [function] 40180 > getAttrKind([snip]) [function] 35811 > clang::DumpCompilerOptionsAction::ExecuteAction() [function] 32417 > llvm::UpgradeIntrinsicCall([snip]) [function] 30239 > bool llvm::InstructionSelect...

...gt; clang::Sema::CheckHexagonBuiltinCpu([snip]) [function] 170316 >> ProcessDeclAttribute([snip]) [function] 125893 >> llvm::AArch64InstPrinter::printAliasInstr([snip]) [function] 105133 >> llvm::AArch64AppleInstPrinter::printAliasInstr([snip]) [function] 105133 >> ParseCodeGenArgs([snip]) [function] 64692 >> unswitchNontrivialInvariants([snip]) [function] 40180 >> getAttrKind([snip]) [function] 35811 >> clang::DumpCompilerOptionsAction::ExecuteAction() [function] 32417 >> llvm::UpgradeIntrinsicCall([snip]) [function] 30239 >> bool llv...

Hi All, Clang pop up with the "error: invalid integral value" diagnostics twice ,when you enable the optimization through -O with a non-integer value i.e -O<non integer> as show below $ clang -Of -S test.c error: invalid integral value 'f' in '-Of' error: invalid integral value 'f' in '-Of' Attached patch fix the issue as $ clang -Of -S

On Thu, Jun 4, 2015 at 5:33 PM, Reid Kleckner <rnk at google.com> wrote: > On Thu, Jun 4, 2015 at 5:17 PM, Teresa Johnson <tejohnson at google.com> wrote: >> >> Agreed. Although I assume you mean invoke the new pass under a >> ThinLTO-only option so that avail extern are not dropped in the >> compile pass before the LTO link? > > > No, this pass

On Thu, Jun 4, 2015 at 3:58 PM, Duncan P. N. Exon Smith < dexonsmith at apple.com> wrote: > > > Personally, I think the right approach is to add a bool to > createGlobalDCEPass defaulting to true named something like > IsAfterInlining. In most standard pass pipelines, GlobalDCE runs after > inlining for obvious reasons, so the default makes sense. The special case > is

...se if (JA.getType() == types::TY_LLVM_IR || Index: lib/Frontend/CompilerInvocation.cpp =================================================================== --- lib/Frontend/CompilerInvocation.cpp (revision 237590) +++ lib/Frontend/CompilerInvocation.cpp (working copy) @@ -489,6 +489,8 @@ static bool ParseCodeGenArgs(CodeGenOptions &Opts, Opts.MergeFunctions = Args.hasArg(OPT_fmerge_functions); + Opts.LTO = Args.hasArg(OPT_flto); + Opts.MSVolatile = Args.hasArg(OPT_fms_volatile); Opts.VectorizeBB = Args.hasArg(OPT_vectorize_slp_aggressive); Index: test/CodeGen/available-externally-suppress....