[llvm-commits] [llvm] r89523 - /llvm/trunk/lib/Transforms/Scalar/SimplifyLibCalls.cpp

[Chris Lattner]

On Dec 4, 2009, at 10:01 PM, Eric Christopher wrote:

>>>> 
>>>>> +    const Type *Ty = Callee->getFunctionType()->getReturnType();
>>>>> +
>>>>> +    if (Const->getZExtValue() < 2)
>>>>> +      return Constant::getAllOnesValue(Ty);
>>>>> +    else
>>>>> +      return ConstantInt::get(Ty, 0);
>>>> 
>>>> I don't really get this.  Why is libcalloptimizer turning these into "I don't know"?  Shouldn't codegen (e.g. codegenprepare) do this?  This seems really wrong.
>>> 
>>> It's doing this now so that these other optimizations below can replace the checking calls with normal calls. It also matches what llvm-gcc did before.  That said, we are producing less checks than we should - I went for keeping existing behavior over trying to get it all right at once.
>> 
>> This should happen in codegenprepare?  libcallsimplify effectively runs at an arbitrary time in the optimizer sequence.  We want the optimizer to be able to prove away these calls (which is why having instcombine do the proving is useful) whenever it can, and then lower them to 'unknown' (and simplify the users) right before codegen.
> 
> The lower to "unknown" is merely a placeholder that keeps current behavior.

What do you mean?

> We do lower to unknown at codegen time already if we didn't before.  It should be all lowered before we get to codegen in one way or another.

Is there code that lowers memcpy_chk(.. unknown)  -> memcpy that happens at codegen time?  If not, lowering the object size intrinsic only will pessimize real cases, no?

-Chris