[PATCH] Caller/Calllee unsafe-fp-math attribute fixup prior to inlining.

Philip Reames listmail at philipreames.com
Tue May 6 13:55:02 PDT 2014


On 05/06/2014 11:46 AM, Chandler Carruth wrote:
>
> On Tue, May 6, 2014 at 11:43 AM, Philip Reames 
> <listmail at philipreames.com <mailto:listmail at philipreames.com>> wrote:
>
>     On 05/05/2014 03:12 PM, Chandler Carruth wrote:
>
>         3) add some more noisy guidance that textual attributes should
>         only be used for *target* attributes, not ones for which
>         IR-optimizers are semantically aware
>
>     Point 3 is the only part of this I disagree with.  One important
>     secondary use for string attributes is while prototyping
>     attributes.  Adding a string attributes is _much_ easier than
>     adding enum ones.  I've got several such string attributes in out
>     of tree branches at the moment.  Most are planned for cleanup and
>     submission (as full attributes), but being able to prototype them
>     rapidly was very useful.
>
>
> Oh, sure. Anything experimental seems fine here. But I wouldn't really 
> expect to start threading such an attribute's semantics through the 
> trunk optimizer... If there was some need to keep an attribute clearly 
> marked "experimental" for a time in trunk until it settled, that also 
> seems not unreasonable. But I don't think that's the situation we're 
> in here.
Agreed.  Just making sure that use case got called out in the discussion 
since your writeup didn't acknowledge it.  Mission accomplished.

Philip

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140506/95ba5cc3/attachment.html>


More information about the llvm-commits mailing list