This patch is to fix https://llvm.org/bugs/show_bug.cgi?id=30213
When composing an expr for ValueOffsetPair, if the value is of pointer type, we can only create a getelementptr instead of sub expr.
Differential D24088
Create a getelementptr instead of sub expr for ValueOffsetPair if the value is a pointer wmi on Aug 31 2016, 9:56 AM. Authored by
Details
This patch is to fix https://llvm.org/bugs/show_bug.cgi?id=30213 When composing an expr for ValueOffsetPair, if the value is of pointer type, we can only create a getelementptr instead of sub expr.
Diff Detail
Event Timeline
Comment Actions Address Sanjoy's comments. I wanted to find a testcase to test the case that the offset is not divisible by the byte size of ETy but didn't succeed, so I forced the code to go through that branch and eyeball the output. Comment Actions
Have you tried writing a C++ test case (in unittests/Analysis)?
Comment Actions I didn't try writing a C++ test case. What I tried was to add an assertion in the branch and run a lot of C/C++ benchmarks but I didn't catch such testcase. What's your idea about writting a C++ testcase?
Comment Actions
Sorry, fat fingered the previous response. By a C++ test case, I meant writing some C++ code that makes the right calls to getSCEV and SCEVExpander::expand to trigger the bad behavior. I'm not sure if that will be easy or even possible, but it is worth a try. Comment Actions I never wrote such unittest before, but I just looked at unittests/Analysis/ScalarEvolutionTest.cpp and felt it was indeed more promising to achieve an expected testcase than writing .ll unitest. I will give it a shot. Thanks for the good suggestion. Comment Actions Create a C++ unittest to exercise the branch where the offset is not divisible by the elem type size of value. Comment Actions lgtm with some comments inline.
|
You don't need to "manually" create an llvm::Function here. Take a look at how other C++ tests use parseAssemblyString and instruction names to avoid this kind of boilerplate.
Having said that, I don't really mind what you have here, it is just under the level of complexity where using parseAssemblyString would pay off.