[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