[llvm-commits] [llvm] r55638 - /llvm/trunk/include/llvm/Function.h

[Chris Lattner]

On Sep 3, 2008, at 10:39 AM, Devang Patel wrote:
> On Sep 3, 2008, at 4:09 AM, Anton Korobeynikov wrote:
>> Hello, Devang
>>
>>> +typedef unsigned FunctionNotes;
>>> +const FunctionNotes FP_None            = 0;
>>> +const FunctionNotes FP_NoInline        = 1<<0;
>>> +const FunctionNotes FP_AlwaysInline    = 1<<1;
>>> +const FunctionNotes FP_OptimizeForSize = 1<<2;
>> I don't see, how this differs from attribute applied to result of
>> function. Also, how this is connected with your proposal? From your
>> proposal I thought, that notes should allow users to pass arbitrary
>> strings to differents parts of their code,  allowing them to parse  
>> and
>> use them accordingly.
>
> No, that was not the goal. These notes are not a replacement for
> annotation instructions.

Ok, but how are these any different from the current function  
attributes that we support (like nounwind)?

>> Are we planning to add new "type" of note here each time we need it?
>> This seems to be pretty inconvenient. What will happen, when we'll
>> have > 64 different notes, or, "variadic" notes, say "foo=N", where N
>> can be any integer (for example, some threshold, etc)?
>
> The idea is to encode the reason that impacts some threshold instead
> of directly encoding threshold. Because the threshold is usually
> specific to a transformation where the reason behind the threshold may
> impact other passes also, for example encoding optimize-for-size is a
> better then encoding inline-threshold=200.

I agree.

> <offtopic> IMO, thresholds are implementation details that never
> should be exposed to end users. We, llvm developers, should fine tune
> them to meet developers' needs. The magic numbers associated with a
> threshold usually confuses developers and restricts llvm developers.
> For example, keep meaning of -inline-threshold=200 consistent even
> though you fixed a bug in how inline costs are calculated! </offtopic>

I really really agree :)

>> Are we planning
>> to drop "custom" notes? If yes - them now I'm just seeing duplicating
>> existing paramattrs functionality.
>
> paramattrs are associated with parameter, this is associated with the
> definition. Some of the paramattrs can be used with call/invoke
> instructions, e.g. nounwind. Where as notes are never associated with
> call/invoke instruction.

I guess that I don't understand what you're saying here.  Are you  
saying that there should be two "namespaces", one for function  
attributes and one for arg/retval attributes?  Are you saying that  
attributes are distinct from notes because attributes are applied to  
call sites also?

It seems that function attributes are strictly more general than  
notes, why not just add these as attributes?

-Chris