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

Daniel Sanders via llvm-dev llvm-dev at lists.llvm.org
Tue Nov 17 14:34:14 PST 2015


> Okay... so Mips unconditionally has -O2 behavior from SelectionDAGISel,
> regardless of the requested optimization level; is that really what you
> wanted?

This code slightly pre-dates my joining LLVM so I don't know the thoughts behind it. I agree it looks wrong though.

> 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 that sums it up. One observation to add: If I make SelectionDAGISel::runOnMachineFunction() unconditionally print the effective optimization level. Mips always picks -O2 as we've discussed but I can't get -O1 for X86 either (I get -O2 instead).

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

I agree.

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


More information about the llvm-dev mailing list