This is an archive of the discontinued LLVM Phabricator instance.

[mips] SelectionDAGISel subclasses now follow the optimization level.
ClosedPublic

Authored by dsanders on Nov 21 2015, 2:20 AM.

Details

Summary

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.

Diff Detail

Event Timeline

dsanders updated this revision to Diff 40863.Nov 21 2015, 2:20 AM
dsanders retitled this revision from to [mips] SelectionDAGISel subclasses now follow the optimization level..
dsanders updated this object.

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.

vradosavljevic added a comment.EditedNov 23 2015, 7:42 AM

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.

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?

dean added a subscriber: dean.Nov 23 2015, 7:45 AM

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.

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?

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?

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?

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.

dean added a comment.Jan 13 2016, 7:24 AM

Hi,

not sure, has this functionality been merged? If not, is not it anymore needed?

It hasn't been committed yet and it seems I've forgotten to ping it. I'll refresh it soon.

dsanders updated this revision to Diff 44838.Jan 14 2016, 1:34 AM

Refresh patch and ping

The code changes look pretty mechanical and straightforward.
But.... *no* tests affected by this?

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.

dsanders updated this revision to Diff 46533.Feb 1 2016, 7:00 AM

It turns out that a very small number of decisions depend on SelectionDAGISel::OptLevel.
One of them is whether DAGCombine merges consecutive stores or not so I've added
a test case based on this.

dsanders updated this revision to Diff 63785.Jul 13 2016, 2:28 AM

Refresh patch as discussed in post-commit comments for r274786

This revision is now accepted and ready to land.Jul 13 2016, 10:52 AM
dsanders closed this revision.Jul 14 2016, 6:32 AM