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

[Eric Christopher]

> 
> 
>> +//===---------------------------------------===//
>> +// 'object size'
>> +namespace {
>> +struct SizeOpt : public LibCallOptimization {
> 
> This code (if it is kept) should be moved to instcombine, and generalized to work on more than just i32/i64.  IT should work on any llvm.objectsize.ixxx intrinsic call. 

Well, there are only two we generate at the moment, but it could be adapted to any since we're just returning a length.  I'm not sure about instcombine itself, but this is likely not the place to put it for sure :)
> 
>> +    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 also handle the case when getOperand(3) and getOperand(4) are both constant ints and op3 <= op4?  If we know that op3 > op4, I'm fine with leaving it unoptimized :)
> 

Good question. I wasn't sure if this pass was iterative? I.e. if I change it to memcpy can the rest of the pass infrastructure deal with it? Of course, I could just look and figure it out - I just hadn't gotten that far :)
> 
> Can this code be factored better?  Maybe introduce a new intermediate class that all of MemCpyChkOpt/MemSetChkOpt/MemMoveChkOpt inherit from that then inherits from LibCallOptimization?

Most assuredly. It was bugging me too :)

-eric