This is an archive of the discontinued LLVM Phabricator instance.

NewGVN: Add UnknownExpression and create them for things we can't symbolize. Kill fragile machinery for handling null expressions.
ClosedPublic

Authored by dberlin on Dec 30 2016, 11:59 PM.

Details

Summary

This avoids the very fragile code for null expressions. We could also use a denseset that tracks which things have null expressions instead, but that seems pretty fragile and premature optimization.

This resolves a number of infinite loop cases, test reductions coming.

Diff Detail

Repository
rL LLVM

Event Timeline

dberlin retitled this revision from to NewGVN: Add UnknownExpression and create them for things we can't symbolize. Kill fragile machinery for handling null expressions..
dberlin updated this object.
dberlin added a reviewer: davide.
dberlin added a subscriber: llvm-commits.
davide edited edge metadata.Jan 2 2017, 6:02 AM

This generally feels like an improvement, but I have a question (inline) about handling of terminators.
I can help reducing the testcase if you provide the original one (not sure which PR this is associated with, if any).

include/llvm/Transforms/Scalar/GVNExpression.h
586 ↗(On Diff #82758)

auto & probably as cast<> makes the type obvious.

lib/Transforms/Scalar/NewGVN.cpp
644–648 ↗(On Diff #82758)

I think we may want to add doxygen documentation to every create* function, but probably that can be done separately in a single pass (if you agree, of course).

1015–1032 ↗(On Diff #82758)

Glad to see this going away =)

1392–1397 ↗(On Diff #82758)

There's another terminator which can return values, i.e. catchswitch. Maybe we should handle it specially here as well? http://llvm.org/docs/LangRef.html#catchswitch-instruction

dberlin marked 2 inline comments as done.Jan 2 2017, 9:05 AM

So, note that i'm wrong about a testcase. This is already test by pr31491.ll.

It's just fixing it in a less fragile way.

lib/Transforms/Scalar/NewGVN.cpp
644–648 ↗(On Diff #82758)

Sure.
What do you want it to say?

There are only a few that have any special behavior. :)

1392–1397 ↗(On Diff #82758)

I think i can just change the test to be about whether the terminator is a void type.
I'll check.

davide accepted this revision.Jan 2 2017, 9:18 AM
davide edited edge metadata.

This looks good with the comment on terminators inline addressed. I wouldn't worry too much about adding a test for catchswitch, but up to you.

lib/Transforms/Scalar/NewGVN.cpp
644–648 ↗(On Diff #82758)

My bad, I was thinking about the perform* class of function. Some of them are commented (sometimes the comment is trivial) and some of them are not. I'd rather have some uniformity there. This one is good, of course, as it doesn't have any specific behaviour.

1392–1397 ↗(On Diff #82758)

Yes, I think that's a more robust way of handling (in case somebody introduces a new terminator etc..)

This revision is now accepted and ready to land.Jan 2 2017, 9:18 AM
davide added a comment.Jan 2 2017, 9:21 AM

Also, after starring at the code for a bit, I think the the idea of introducing an explicit UnknownExpression class instead of having specialized code logic for handling it is very nice. I think it also makes the code easier to read/understand. I did some profiling (on llvm itself, and on some internal benchmarks) and I haven't noticed this handling popping up so I think not using a DenseSet for now is the right thing)

dberlin marked an inline comment as done.Jan 2 2017, 9:37 AM

The testcase we'd want, i think, is to have an invoke and a catchswitch that both return values.
Previously, it should have considered them the same value, i think.

I actually discovered that part while looking at this comment:

// FIXME: We should eventually be able to replace everything still
// in the initial class with undef, as they should be unreachable.
// Right now, initial still contains some things we skip value
// numbering of (UNREACHABLE's, for example)."

it contained a few invoke's, so i went hunting why.

This revision was automatically updated to reflect the committed changes.