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

Robinson, Paul via llvm-dev
Tue, 17 Nov 2015 21:22:56 -0000

> > > > 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