[llvm-commits] [cfe-commits] Extend Attributes to 64 bits (wrapped in a class), add one more attribute for address safety checking

Kaelyn Uhrain rikka at google.com
Thu Jan 19 10:17:44 PST 2012


On Thu, Jan 19, 2012 at 10:16 AM, Kostya Serebryany <kcc at google.com> wrote:

>
>
> On Thu, Jan 19, 2012 at 10:14 AM, Kaelyn Uhrain <rikka at google.com> wrote:
>
>> On Thu, Jan 19, 2012 at 9:56 AM, Kostya Serebryany <kcc at google.com>wrote:
>>
>>>
>>>
>>> On Thu, Jan 19, 2012 at 1:18 AM, Anton Korobeynikov <
>>> anton at korobeynikov.info> wrote:
>>>
>>>> Hi Kostya,
>>>>
>>>>
>>>> > The patches are attached, the llvm patch is also published
>>>> > here: http://codereview.appspot.com/5544058/
>>>> What is the performance impact of this?
>>>>
>>>
>>> Good point (I assume you mean compile-time performance, not the
>>> performance of compiled programs).
>>> I've verified that the compile-time did not change by building 403.gcc
>>> and 483.xalancbmk with the original and modified clang with -O1.
>>>
>>
>> Out of curiosity did you check the compile-time performance for 64-bit
>> clang/llvm,
>>
>
> 64-bit.
> On 32-bit there may be some change indeed, but we still need more
> attributes, right? :)
>

Their necessity would be all the more reason to understand the performance
impact on a 32-bit compiler. :)


>
>
>> 32-bit clang/llvm, or both?  I would imagine that extending attributes to
>> 64-bit would have negligible impact for a 64-bit compiler binary but
>> potentially greater impact for a 32-bit one as they would no longer fit in
>> a single register.
>>
>> Cheers,
>> Kaelyn
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120119/4c4a4c4c/attachment.html>


More information about the llvm-commits mailing list