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

Wed Nov 18 10:42:02 PST 2015

The driving goal of 'optnone' is to have an easy way for programmers to get an "-O0 like" debugging experience for selected functions, without making them build everything with –O0.
To that end, we turn off as much optimization as we reasonably can, but in the context of a pipeline that is generally expecting optimizations to be enabled, in practice we can't exactly match –O0 because "things break" if we turn off everything.  Luckily, exactly matching –O0 isn't a requirement.

Contemplating the "things break" situation, I am entirely willing to believe (it may have actually happened) that problems can occur when using FastISel in a pipeline that isn't expecting it.  So, for purposes of diagnosing these 'optnone' problems, it seems useful to be able to force 'optnone' not to use FastISel.  This is a different motivation than Daniel expressed, which is a more principled idea coming from the "optnone should exactly match –O0" misconception; but the conclusion (that we should respect an explicit –fast-isel=false within 'optnone' functions) is the same.
--paulr

From: Eric Christopher [mailto:echristo at gmail.com]
Sent: Wednesday, November 18, 2015 9:48 AM
To: Robinson, Paul; Daniel Sanders; llvm-dev at lists.llvm.org
Subject: Re: [llvm-dev] Mips unconditionally uses fast-isel?

I'd have figured optnone was "no optimizations" not "use the entire O0 code path"?

At least that seemed to be the intent when you added it Paul?

-eric

On Wed, Nov 18, 2015 at 8:05 AM Robinson, Paul via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:
Well, 'optnone' is already not identical to –O0, and given the nature of things, probably can't be; but I am persuaded that it's reasonable for it to honor the –fast-isel option as a debugging tactic.  I'll take an AI to make this happen.
Thanks,
--paulr
P.S. One nit, the "O0 + optnone" case should not have an asterisk, the FastISel flag is not manipulated if the opt level is already zero. Does not affect the strength of your argument, of course.

From: Daniel Sanders [mailto:Daniel.Sanders at imgtec.com<mailto:Daniel.Sanders at imgtec.com>]
Sent: Wednesday, November 18, 2015 2:19 AM
To: Robinson, Paul; llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>

Subject: RE: Mips unconditionally uses fast-isel?

> -----Original Message-----

> From: Robinson, Paul [mailto:Paul_Robinson at playstation.sony.com]

> Sent: 17 November 2015 22:58

> To: Daniel Sanders; llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>

> Subject: RE: Mips unconditionally uses fast-isel?

>

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

> >

> > I think we should do that as well. I don't think it's right that optnone

> > enables Fast ISel even when it's been explicitly disabled. It should do

> > the same checks as addPassesToGenerateCode() does.

>

> Hm?  What you're asking for is that "-O2" and "-O2 -fast-isel=none" are

> identical, unless you have an 'optnone' function. Do you really have a

> use-case for controlling the codegen path for an 'optnone' function?

> The whole point of 'optnone' is to avoid optimizations.

> --paulr

>

No, that's already true. -O2 doesn't try to enable Fast ISel (unless the optnone attribute is given) so –fast-isel=false has no effect.

I'm saying that optnone means 'use –O0 for this function' and that optnone should

respect non-default values of the -fast-isel flag like –O0 does. This is the behaviour I'd expect:

-fast-isel=false

-fast-isel=default

-fast-isel=true

-O0

SelectionDAG

FastISel

FastISel

-O0 + optnone attribute

SelectionDAG*

FastISel

FastISel

-O1 + optnone attribute

SelectionDAG*

FastISel

FastISel

-O2 + optnone attribute

SelectionDAG*

FastISel

FastISel

-O3 + optnone attribute

SelectionDAG*

FastISel

FastISel

-O1

SelectionDAG

SelectionDAG

FastISel

-O2

SelectionDAG

SelectionDAG

FastISel

-O3

SelectionDAG

SelectionDAG

FastISel

The cells marked with '*' differ from the current behaviour.

In terms of code, I think this part of OptLevelChanger::OptLevelChanger():

   if (NewOptLevel == CodeGenOpt::None) {

      DEBUG(dbgs() << "\nEnable FastISel for Function "

            << IS.MF->getFunction()->getName() << "\n");

      IS.TM.setFastISel(true);

    }

Should be:

    if (NewOptLevel == CodeGenOpt::None) {

      DEBUG(dbgs() << "\nEnable FastISel for Function "

            << IS.MF->getFunction()->getName() << "\n");

      IS.TM.setFastISel(EnableFastISelOption != cl::BOU_FALSE);

    }

Where EnableFastISelOption has the same value as the global in LLVMTargetMachine.cpp

The main reason I'm asking for this is that I think it's weird to for optnone to use a different code generator

than  –O0. These hidden overrides exist to help us debug code generation problems and, faced with a code

generation bug, –fast-isel=false is useful for quickly determining whether it's in FastISel or somewhere else.

The current behaviour allows optnone to overrule the hidden option to force-disable FastISel which will give

misleading guidance for bugs that lie in functions with optnone.
_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151118/d11aa90d/attachment.html>