[llvm-commits] [PATCH] Move function prototype attribute inference to instcombine

[Benjamin Kramer]

On 02.12.2012, at 19:17, Meador Inge <meadori at codesourcery.com> wrote:

> 
> On Nov 30, 2012, at 3:48 AM, Chandler Carruth wrote:
> 
>> On Thu, Nov 29, 2012 at 11:25 PM, Owen Anderson <resistor at mac.com> wrote:
>>> 
>>> On Nov 29, 2012, at 10:16 PM, Duncan Sands <baldrick at free.fr> wrote:
>>> 
>>>> Hi Meador,
>>>> 
>>>> On 30/11/12 06:22, Meador Inge wrote:
>>>>> The simplify-libcalls pass implemented a doInitialization hook to infer
>>>>> function prototype attributes for well-known functions.  Now that library
>>>>> call simplification is being carried out in instcombine it makes sense to
>>>>> move the attribute inference there as well.
>>>> 
>>>> I'm not a big fan of doInitialization personally.  Couldn't you do it lazily
>>>> the first time that they are needed instead?
>>> 
>>> Indeed, Pedro has been working with the ASAN/TSAN guys to clean up and remove this kind of behavior in doInitialization on their passes.
>> 
>> Yea, I don't know why this was ever remotely OK to do in
>> doInitialization. It's terrible.
>> 
>> I feel like this should be part of the existing 'functionattrs' pass
>> which is already responsible for inferring attributes to functions,
>> just as instcombine was already responsible for scalar
>> simplifications.
> 
> Ah, good point -- I didn't fully notice that pass.  I have moved the
> attribute inference logic to the functionattrs pass.  The main difference
> is that the library call attribute inference won't happen when '-fno-unit-at-a-time'
> is thrown (I suppose that is OK).  Does the attached look OK?

I don't think it is safe to add attributes without asking TargetLibraryInfo if the function is available first. Can you add a  check?

-Ben