It was recently discovered that, for Mips's SelectionDAGISel subclasses,
all optimization levels caused SelectionDAGISel to behave like -O2.
This change adds the necessary plumbing to initialize the optimization level.
Differential D14900
[mips] SelectionDAGISel subclasses now follow the optimization level. dsanders on Nov 21 2015, 2:20 AM. Authored by
Details It was recently discovered that, for Mips's SelectionDAGISel subclasses, This change adds the necessary plumbing to initialize the optimization level.
Diff Detail Event TimelineComment Actions I'm not sure what to do about the test. I've preserved what it was really testing for now but I believe the intention was to test SelectionDAG and not FastISel. Unfortunately, reverting the original change that added this test (rL237153) does not change the output of SelectionDAG. Added the author and commit-er for their opinion. Comment Actions In this test we're checking that register scavenging spill slot is close to $fp, but this commit (http://reviews.llvm.org/rL238829) changed the essence of this test. Any reason why this happened? Comment Actions The test looks likes it's trying to create enough register pressure to induce the use of the "scavenging spill slot," but that would depend on exactly what the DAG looks like and which register allocator pass you're using. The -O0/-O2 confusion, -fast-isel=false, and 'optnone' tweaks all seem to be attempts to set up exactly the right conditions. Is there a way to control pass selection more directly? Comment Actions
The main aim of r238829 was to correctly align vector locals on the stack since (in the O32 ABI) the maximum alignment is 8 and vectors need 16*. The test uses a few vectors so that explains why it was affected, however dynamic stack realignment reserves an additional register so I'd have thought it would make triggering the register scavenger more likely. I'll take a closer look. *Actually, they only need element-size alignment but I don't think we can describe that and we should get better performance from 16 anyway. Comment Actions It hasn't been committed yet and it seems I've forgotten to ping it. I'll refresh it soon. Comment Actions The code changes look pretty mechanical and straightforward. Comment Actions There was one test affected in my original branch but it was the same test change as your patch and fell out when I rebased beyond your commit. I expect I can find another test case. Comment Actions It turns out that a very small number of decisions depend on SelectionDAGISel::OptLevel. |