[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