Displaying 8 results from an estimated 8 matches for "fpasses".
Did you mean:
passes
2016 May 10
2
Some questions about phase ordering in OPT and LLC
...o AFAIK no, you should get the order you specified on the command line, i.e.
>
> 1. mymodulepass0
> 2. myfunctionpass on each function
> 3. mymodulepass1
MMMh, from opt.cpp, there's a first call to:
if (OptLevelO1 || OptLevelO2 || OptLevelOs || OptLevelOz || OptLevelO3) {
FPasses->doInitialization();
for (Function &F : *M)
FPasses->run(F);
FPasses->doFinalization();
}
then a few lines later, a call to:
Passes.run(*M);
where Passes is the Module pass Manager and FPasses is the Function Pass
Manager. Each is filled in AddOptimizationPasses...
2009 Feb 13
0
[LLVMdev] loop passes vs call graph
Hi,
> I'm looking at bug 3367.
>
> If I run:
>
> $ opt b.bc -inline -loop-rotate -loop-unswitch -debug-pass=Executions
>
> ... it eventually crashes in the inliner, because the call graph isn't
> up to date. (NB if you want to reproduce this you'll have to apply my
> patch from bug 3367 first.)
>
> The reason the call graph isn't up to date is
2009 Feb 13
3
[LLVMdev] loop passes vs call graph
I'm looking at bug 3367.
If I run:
$ opt b.bc -inline -loop-rotate -loop-unswitch -debug-pass=Executions
... it eventually crashes in the inliner, because the call graph isn't
up to date. (NB if you want to reproduce this you'll have to apply my
patch from bug 3367 first.)
The reason the call graph isn't up to date is that -loop-unswitch has
changed a function and not updated
2009 Feb 16
1
[LLVMdev] loop passes vs call graph
On Feb 13, 2009, at 5:39 AM, Duncan Sands wrote:
> Hi,
>
>> I'm looking at bug 3367.
>>
>> If I run:
>>
>> $ opt b.bc -inline -loop-rotate -loop-unswitch -debug-pass=Executions
>>
>> ... it eventually crashes in the inliner, because the call graph
>> isn't
>> up to date. (NB if you want to reproduce this you'll have to
2016 May 09
2
Some questions about phase ordering in OPT and LLC
On Mon, May 09, 2016 at 01:07:07PM -0700, Mehdi Amini via llvm-dev wrote:
>
> > On May 9, 2016, at 10:43 AM, Ricardo Nobre via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> >
> > Hi,
> >
> > I'm a PhD student doing phase ordering as part of my PhD topic and I would like to ask some questions about LLVM.
> >
> > Executing the following
2006 Jan 10
0
[LLVMdev] passmanager, significant rework idea...
On Mon, 9 Jan 2006, Saem Ghani wrote:
> The patch below basically hammers out some ideas as to where I'd like
> to take the passmanager in LLVM. I've tried thinking things through,
> but I'm still a n00b, so some criticism would be more than welcome. =)
>
> Starting from line 191 down. If you're wondering why I created a
> patch, well that's because I found
2006 Jan 10
3
[LLVMdev] passmanager, significant rework idea...
The patch below basically hammers out some ideas as to where I'd like
to take the passmanager in LLVM. I've tried thinking things through,
but I'm still a n00b, so some criticism would be more than welcome. =)
Starting from line 191 down. If you're wondering why I created a
patch, well that's because I found thinking in passmanagert.h the most
productive.
--
Regards.
2006 Jan 10
1
[LLVMdev] Re: passmanager, significant rework idea...
On 1/10/06, Chris Lattner <sabre at nondot.org> wrote:
> Interesting approach. :)
Thanks.
> Comments below, with ***'s before the notes:
> +class LoopPass : public Pass {}; // Temporary.
>
> *** I wouldn't worry about loop passes yet.
Sure.
> +class PassUnit {
> + Pass *pass;
> +
> + enum Traversal {
> + LINEAR, // Standard top down