[llvm-dev] status of IPO/IPCP?

Davide Italiano via llvm-dev llvm-dev at lists.llvm.org
Wed May 4 15:33:17 PDT 2016


On Wed, May 4, 2016 at 3:31 PM, Davide Italiano <davide at freebsd.org> wrote:
> On Tue, May 3, 2016 at 11:52 PM, Davide Italiano <davide at freebsd.org> wrote:
>> On Tue, May 3, 2016 at 11:01 PM, Justin Bogner <mail at justinbogner.com> wrote:
>>> Sean Silva via llvm-dev <llvm-dev at lists.llvm.org> writes:
>>>> No tests fail with the patch below, so I would say it's pretty useless. It
>>>> seems that the C bindings are the only user but we can probably just have them
>>>> return IPSCCP instead.
>>>
>>> I don't necessarily think your conclusion is wrong, but the patch isn't
>>> proving what you think it's proving. In fact, the below passes all tests
>>> as well. When you call passes through `opt` they don't end up calling
>>> through the createXYZPass path.
>>>
>>> diff --git a/lib/Transforms/IPO/IPConstantPropagation.cpp b/lib/Transforms/IPO/IPConstantPropagation.cpp
>>> index b3ee499..8d70b98 100644
>>> --- a/lib/Transforms/IPO/IPConstantPropagation.cpp
>>> +++ b/lib/Transforms/IPO/IPConstantPropagation.cpp
>>> @@ -253,7 +253,9 @@ char IPCP::ID = 0;
>>>  INITIALIZE_PASS(IPCP, "ipconstprop",
>>>                  "Interprocedural constant propagation", false, false)
>>>
>>> -ModulePass *llvm::createIPConstantPropagationPass() { return new IPCP(); }
>>> +ModulePass *llvm::createIPConstantPropagationPass() {
>>> +  llvm_unreachable("fnord");
>>> +}
>>>
>>
>> I think this should do the job:
>>
>> $ grep -R 'ipconstprop' * | wc -l
>>    7
>> $ sed -i.bak 's/ipconstprop/ipsccp/' *
>> $ grep -R 'ipconstprop' * | wc -l
>>        0
>>
>> and two tests are actually failing :|
>>
>> Testing Time: 0.10s
>> ********************
>> Failing Tests (2):
>>     LLVM :: Transforms/IPConstantProp/return-argument.ll
>>     LLVM :: Transforms/IPConstantProp/return-constants.ll
>>
>>   Expected Passes    : 11
>>   Unexpected Failures: 2
>>
>> I'll take a closer look tomorrow.
>>
>>

I analyzed this and realized there are some cases that are actually
not handled properly by SCCP but they are by the naive algorithm. For
example, in return-argument SCCP doesn't propagate the return value
correctly, so the result is

  %Z = add  i32 X1, X2

instead of

  %Z = add i32 1, 3


I suspect this is because IPSCCP doesn't (yet) handle multiple ret
value instructions.

-- 
Davide

"There are no solved problems; there are only problems that are more
or less solved" -- Henri Poincare


More information about the llvm-dev mailing list