Displaying 9 results from an estimated 9 matches for "fpmanager".
Did you mean:
opmanager
2008 Jan 29
4
[LLVMdev] PassManager Mysteries
On Monday 28 January 2008 09:31:11 pm Owen Anderson wrote:
> From experience, an important point that is often forgotten is that
> the order of declaration of dependencies matter. If you declare that
> you require pass A, and then pass B, and B doesn't preserve A, you'll
> get an error like this.
>
> Just some advice from having had similar problems in the past.
2018 May 07
2
Preservation of CallGraph (by BasicBlockPass, FunctionPass)
...of BasicBlockPass it seems to be legal to remove calls, and that should not impact the CFG, right? But it will impact the CallGraph.
I believe that when the FunctionPass Manager is used from within the Call Graph SCC Pass Manager, then the CGPassManager will check the modification status from the FPManager and call RefreshCallGraph() (or set CallGraphUpToDate=false;) in case modification had been done. Thus, it seems to be legit for a FunctionPass (and thereby also the FunctionPassManager) to not always preserve the CallGraph. And I think this is handled within the CGPassManager, but not when FPManag...
2018 May 07
0
Preservation of CallGraph (by BasicBlockPass, FunctionPass)
...to
> remove calls, and that should not impact the CFG, right? But it will impact
> the CallGraph.
>
>
>
> I believe that when the FunctionPass Manager is used from within the Call
> Graph SCC Pass Manager, then the CGPassManager will check the modification
> status from the FPManager and call RefreshCallGraph() (or set
> CallGraphUpToDate=false;) in case modification had been done. Thus, it seems
> to be legit for a FunctionPass (and thereby also the FunctionPassManager) to
> not always preserve the CallGraph. And I think this is handled within the
> CGPassManager,...
2018 May 08
2
Preservation of CallGraph (by BasicBlockPass, FunctionPass)
...ot impact the CFG, right? But it will impact
> > the CallGraph.
> >
> >
> >
> > I believe that when the FunctionPass Manager is used from within the Call
> > Graph SCC Pass Manager, then the CGPassManager will check the
> modification
> > status from the FPManager and call RefreshCallGraph() (or set
> > CallGraphUpToDate=false;) in case modification had been done. Thus, it
> seems
> > to be legit for a FunctionPass (and thereby also the FunctionPassManager)
> to
> > not always preserve the CallGraph. And I think this is handled within...
2018 May 08
0
Preservation of CallGraph (by BasicBlockPass, FunctionPass)
...> > > the CallGraph.
> > >
> > >
> > >
> > > I believe that when the FunctionPass Manager is used from within the
> Call
> > > Graph SCC Pass Manager, then the CGPassManager will check the
> > modification
> > > status from the FPManager and call RefreshCallGraph() (or set
> > > CallGraphUpToDate=false;) in case modification had been done. Thus, it
> > seems
> > > to be legit for a FunctionPass (and thereby also the
> FunctionPassManager)
> > to
> > > not always preserve the CallGraph. And...
2013 Oct 27
3
[LLVMdev] Why is the loop vectorizer not working on my function?
...ine = 0;
if (ModuleTriple.getArch())
Machine = GetTargetMachine(Triple(ModuleTriple));
OwningPtr<TargetMachine> TM(Machine);
// Add internal analysis passes from the target machine.
if (TM.get())
TM->addAnalysisPasses(Passes); // <<<
…
TM->addAnalysisPasses(FPManager);
Here is what the target does:
void X86TargetMachine::addAnalysisPasses(PassManagerBase &PM) {
// Add first the target-independent BasicTTI pass, then our X86 pass. This
// allows the X86 pass to delegate to the target independent layer when
// appropriate.
PM.add(createBasicTargetTr...
2013 Oct 27
0
[LLVMdev] Why is the loop vectorizer not working on my function?
...Machine = GetTargetMachine(Triple(ModuleTriple));
> OwningPtr<TargetMachine> TM(Machine);
>
> // Add internal analysis passes from the target machine.
> if (TM.get())
> TM->addAnalysisPasses(Passes); // <<<
> …
> TM->addAnalysisPasses(FPManager);
>
> Here is what the target does:
>
> void X86TargetMachine::addAnalysisPasses(PassManagerBase &PM) {
> // Add first the target-independent BasicTTI pass, then our X86 pass. This
> // allows the X86 pass to delegate to the target independent layer when
> // appro...
2013 Oct 26
0
[LLVMdev] Why is the loop vectorizer not working on my function?
I would need this to work when calling the vectorizer through
the function pass manager. Unfortunately I am having the same
problem there:
LV: The Widest type: 32 bits.
LV: The Widest register is: 32 bits.
It's not picking the target information, although I tried with and
without the target triple in the module.
Any idea what could be wrong?
Frank
On 26/10/13 15:54, Hal Finkel wrote:
2013 Oct 26
3
[LLVMdev] Why is the loop vectorizer not working on my function?
----- Original Message -----
> >>> LV: The Widest type: 32 bits.
> >>> LV: The Widest register is: 32 bits.
>
> Yep, we don’t pick up the right TTI.
>
> Try -march=x86-64 (or leave it out) you already have this info in the
> triple.
>
> Then it should work (does for me with your example below).
That may depend on what CPU is picks by default; Frank,