Displaying 4 results from an estimated 4 matches for "postraschedulerid".
Did you mean:
postrascheduler
2013 Nov 23
2
[LLVMdev] prevents instruction-scheduler from interfereing instruction pair
...g pass.
addPass(&ExpandPostRAPseudosID);
printAndVerify("After ExpandPostRAPseudos");
// Run pre-sched2 passes.
if (addPreSched2())
printAndVerify("After PreSched2 passes");
// Second pass scheduler.
if (getOptLevel() != CodeGenOpt::None) {
addPass(&PostRASchedulerID);
printAndVerify("After PostRAScheduler");
}
secondly, psuedo instruction is kind of compiler internal representation. I
wish our instruction pair can disclose to programmer. intrinsics can do
that.
thanks,
--lx
On Fri, Nov 22, 2013 at 9:45 PM, Amara Emerson <amara.emerson a...
2013 Nov 23
0
[LLVMdev] prevents instruction-scheduler from interfereing instruction pair
...D);
> printAndVerify("After ExpandPostRAPseudos");
>
> // Run pre-sched2 passes.
> if (addPreSched2())
> printAndVerify("After PreSched2 passes");
>
> // Second pass scheduler.
> if (getOptLevel() != CodeGenOpt::None) {
> addPass(&PostRASchedulerID);
> printAndVerify("After PostRAScheduler");
> }
>
>
> secondly, psuedo instruction is kind of compiler internal representation. I
> wish our instruction pair can disclose to programmer. intrinsics can do
> that.
>
> thanks,
> --lx
>
>
> On Fri...
2013 Nov 23
1
[LLVMdev] prevents instruction-scheduler from interfereing instruction pair
...pandPostRAPseudos");
> >
> > // Run pre-sched2 passes.
> > if (addPreSched2())
> > printAndVerify("After PreSched2 passes");
> >
> > // Second pass scheduler.
> > if (getOptLevel() != CodeGenOpt::None) {
> > addPass(&PostRASchedulerID);
> > printAndVerify("After PostRAScheduler");
> > }
> >
> >
> > secondly, psuedo instruction is kind of compiler internal
> representation. I
> > wish our instruction pair can disclose to programmer. intrinsics can do
> > that.
> >...
2016 Jun 08
2
Instruction Itineraries: question about operand latencies
I overrode getInstrLatency and did some printing to see what is available
there. It looks like the registers are still virtual at that point when
getInstrLatency is called - is that correct? (we needed to make some
decisions based on actual registers that have been assigned since some
registers are reserved as address space pointers and we could vary the
latency based on which address space