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

Meador Inge meadori at codesourcery.com
Sun Dec 2 10:17:06 PST 2012


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?

--
Meador Inge
CodeSourcery / Mentor Embedded
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Move-library-call-prototype-attribute-inference-to-f.patch
Type: application/octet-stream
Size: 55575 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20121202/c4fc6ca2/attachment.obj>


More information about the llvm-commits mailing list