The fmuladd intrinsic is described as saying that a multiply and addition sequence can be fused into an fma instruction "if the code generator determines that the fused expression would be legal and efficient". (http://llvm.org/docs/LangRef.html#llvm-fma-intrinsic) I've spent a bit of time puzzling over how a code generator is supposed to know if it's legal to generate an fma instead of a multiply and add - surely that's something for the frontend to determine, based on the FP_CONTRACT setting, and not something for the code generator to work out? However, recently I came across http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20120528/0582 22.html which explains that "legal" in the above definition doesn't mean legal from the point of view of the source language, but simply means whether or not the target architecture has an fma instruction. The thread also talks about updating the documentation to clarify this, but that doesn't seem to have happened. Assuming that the thread I've linked to is correct, would it be possible to clarify the IR spec accordingly? I think that the current use of the word "legal" is misleading. Andrew -- Andrew Booker, Staff Software Engineer Media Processing Division ARM Ltd, 110 Fulbourn Road, Cambridge CB1 9NJ, UK Tel: +44 1223 400695 Fax: +44 1223 400410
Thanks for all the replies - it pretty much confirmed what I think I'd worked out about how fmuladd is supposed to behave. But my initial query wasn't asking what fmuladd did - it was asking for the documentation about it to be clarified. Can I suggest that the Overview section for fmuladd is changed to say the following (the key point being the removal of the word "legal" in the description, to avoid confusion with whether the optimisation is legal from the point of view of the source language): The llvm.fmuladd.* intrinsic functions represent multiply-add expressions that can be fused if the code generator determines that the target instruction set has support for a fused expression, and that its use would be efficient. Andrew -- Andrew Booker, Staff Software Engineer Media Processing Division ARM Ltd, 110 Fulbourn Road, Cambridge CB1 9NJ, UK Tel: +44 1223 400695 Fax: +44 1223 400410 -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Hi Andrew, That seems like a useful clarification. I've updated the docs with your suggested text (with some tweaks) in r172680. Thanks for the suggestion. Cheers, Lang. On Mon, Jan 14, 2013 at 5:25 AM, Andrew Booker <Andrew.Booker at arm.com>wrote:> Thanks for all the replies - it pretty much confirmed what I think I'd > worked out about how fmuladd is supposed to behave. > > But my initial query wasn't asking what fmuladd did - it was asking for > the documentation about it to be clarified. Can I suggest that the > Overview section for fmuladd is changed to say the following (the key > point being the removal of the word "legal" in the description, to > avoid confusion with whether the optimisation is legal from the point > of view of the source language): > > The llvm.fmuladd.* intrinsic functions represent multiply-add > expressions that can be fused if the code generator determines that the > target instruction set has support for a fused expression, and that its > use would be efficient. > > Andrew > > -- > Andrew Booker, Staff Software Engineer > Media Processing Division > ARM Ltd, 110 Fulbourn Road, Cambridge CB1 9NJ, UK > Tel: +44 1223 400695 Fax: +44 1223 400410 > > > > -- IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130116/fc210063/attachment.html>