[PATCH] instcombine: Only create library call simplifier once

Michael Ilseman milseman at apple.com
Fri Mar 8 13:49:36 PST 2013


Looking at the code once more.

I don't think having intrinsics in that map makes sense. The LibCalls are needed because of target-defined name mappings, but intrinsics have IntrinsicID which is the same for all targets.

I'll pull them out of that table and have a simple, short lookup function for intrinsics (just a switch on the ID). That way we can fast-path things which don't need complicated string matching/mappings to recognize.

On Mar 7, 2013, at 5:37 PM, Nadav Rotem <nrotem at apple.com> wrote:

> Hi Meador, 
> 
> I spoke with Bill about this and I now think that your proposal to initialize the SimplifyLibCalls on the first invocation of runOnFunction is correct. The only exception is LTO build. On LTO builds we can change the TargetData and TLI per-function. So, on each runOnFunction we need to check of the current TLI and DataLayout is the same as the previous run. If it is not the we need to re-initialize the SimpLibCalls, rehash the table, etc. 
> 
> Thanks,
> Nadav
> 
> On Mar 7, 2013, at 4:39 PM, Meador Inge <meadori at codesourcery.com> wrote:
> 
>> On 03/07/2013 04:34 PM, Michael Ilseman wrote:
>> 
>>> Oh, I see, you're wanting to cache the hash table from the first call.
>>> Unfortunately, this method seems dangerous and contrary to the design
>>> of the PassManager. Is there some higher-level structure that it makes
>>> sense to pin it to? For example, maybe the TargetLibraryInfo, Module,
>>> LLVMContext, etc would make sense.
>> 
>> Hmmmm.  So in general how to I dynamically create a new object for a pass that
>> is independent of any function being transformed by a FunctionPass?  The docs
>> make it sound like this is what 'doInitialization' is for [1].  However, that
>> doesn't seem to work because I need access to the 'TargetLibraryInfo'.  Also, I
>> have been steered away from 'doInitialization' in past reviews.
>> 
>> FWIW, the old SimplifyLibCalls pass that I migrated all of this from was
>> already doing something quite similar:
>> 
>>  class SimplifyLibCalls : public FunctionPass {
>>    TargetLibraryInfo *TLI;
>> 
>>    StringMap<LibCallOptimization*> Optimizations;
>>    ...
>>  }
>> 
>>  bool SimplifyLibCalls::runOnFunction(Function &F) {
>>    TLI = &getAnalysis<TargetLibraryInfo>();
>> 
>>    if (Optimizations.empty())
>>      InitOptimizations();
>> 
>>    ...
>>   }
>> 
>> I guess it shouldn't have been doing that?
>> 
>> [1] http://llvm.org/docs/WritingAnLLVMPass.html#the-doinitialization-module-method
>> 
>> -- 
>> Meador Inge
>> CodeSourcery / Mentor Embedded
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130308/a81e0681/attachment.html>


More information about the llvm-commits mailing list