[llvm-dev] Mips unconditionally uses fast-isel?

[Robinson, Paul via llvm-dev]

> > > > I was mucking around in FastISel, and was surprised to see the test
> > > >   llvm/test/CodeGen/Mips/emergency-spill-slot-near-fp.ll
> > > > failed.  This was surprising because it specifies -fast-isel=false.
> > > >
> > > > Does the Mips code generator use fast-isel even when you ask it not
> to?
> > > > Thanks,
> > > > --paulr
> > >
> > > This seems to be an all-targets bug. There's code in OptLevelChanger
> > > (lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp) that forces Fast ISel
> to
> > > be enabled for every -O0 function.
> >
> > Well.... the test specifies -O0 so even though the function is marked
> > 'optnone' I'd expect OptLevelChanger to be a no-op, because it checks
> > whether the old and new OptLevel are the same. Which they should be.
> >
> > If I use -debug-only=isel I see it is changing from -O2 to -O0, which
> > makes me think the "real" bug is that llc is ignoring -O0.
> > --paulr
> 
> Looking further, I think it's a bit of both. Enabling Fast ISel when -
> fast-isel=false is given doesn't make sense but there are also five
> targets (Mips, BPF, Sparc, PPC, and AMDGPU) that use the
> SelectionDAGISel(TargetMachine &) constructor which leave the optimization
> level at the default. The other targets all pass on the optimization level
> using the two argument constructor.

Okay... so Mips unconditionally has -O2 behavior from SelectionDAGISel,
regardless of the requested optimization level; is that really what you 
wanted?
												|
For this particular test, the -O0 is ignored and becomes -O2, which 
defaults to -fast-isel=false, and then 'optnone' is actually where you 
get the -O0 effect. Except that 'optnone' also turns ON fast-isel, which 
you didn't notice because it didn't actually matter, until I came along 
and started mucking around in FastISel.

I think if Mips wants -O0 to work in llc, then it really needs to be 
passed in to SelectionDAGISel.  Then take 'optnone' off the function in 
this test, and it should all Just Work.  And the test would actually be
exercising the non-fast-isel path, which it seems is what you wanted?

The other thing that might work, is having TargetMachine remember how
the fast-isel option got set, and make OptLevelChanger do the right
thing. But that seems like a hack to work around Mips not obeying the
specified optimization level, honestly.

Thanks,
--paulr