[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