[FuzzMutate] Allow only sized pointers for the GEP instruction
ClosedPublic

Authored by igor-laevsky on Tue, Dec 5, 6:57 AM.

Details

Summary

We can't use arbitrary pointers inside of the GEP instruction. What we really need is a pointer which points to the sized object. There are potentially more constraints if we will ever generate more than a single index but this should work for now.

Diff Detail

Repository
rL LLVM
igor-laevsky created this revision.Tue, Dec 5, 6:57 AM
bogner added inline comments.Tue, Dec 5, 3:22 PM
unittests/FuzzMutate/OperationsTest.cpp
16–19 ↗(On Diff #125520)

Please keep these sorted. clang-format can do that for you.

57–59 ↗(On Diff #125520)

I don't know gtest all that well, but is putting all of this in an anonymous namespace the right thing to do here? Why not just make parseAssembly static?

179–180 ↗(On Diff #125520)

Apparently phabricator only shows the diff here in the email and not the we interface, but what's with the arbitrary whitespace changes on these Function::Create calls? According to clang-format, the old way is correct.

294–298 ↗(On Diff #125520)

I feel like these would be easier to understand / wouldn't need the comments if we create the instructions programmatically like in the other tests in this file rather than parsing it.

igor-laevsky added inline comments.Wed, Dec 6, 3:06 AM
unittests/FuzzMutate/OperationsTest.cpp
57–59 ↗(On Diff #125520)

I see anonymous namespace in the official gtest examples and in many llvm test sets. So I guess it's the right thing to do.

179–180 ↗(On Diff #125520)

Hm, didn't notice those. Will run clang format, thanks.

294–298 ↗(On Diff #125520)

I tried this way but it seemed harder to read, harder to write and more error prone. After all we want to generate llvm ir code and there is no more natural way than to write it directly.

bogner accepted this revision.Wed, Dec 6, 11:29 AM
bogner added inline comments.
unittests/FuzzMutate/OperationsTest.cpp
57–59 ↗(On Diff #125520)

Works for me.

294–298 ↗(On Diff #125520)

I'm not totally convinced. Harder to write maybe, but at least in concert with figuring out what the checks are doing I feel it's easier to read and less error prone. It's not a big deal though, both ways are clear enough.

This revision is now accepted and ready to land.Wed, Dec 6, 11:29 AM
This revision was automatically updated to reflect the committed changes.