It does not appear that we've documented that constrained FP intrinsics cannot be mixed in a single function with non-constrained instructions. This patch fixes that.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
My understanding was that this is a temporary restriction; in the end, the goal is to allow mixing constrained an non-constrained operations, once we have the necessary barriers. Did I misunderstand this?
Now, I guess it still makes sense to document the restriction even if it is temporary, I'm just wondering whether this should be made explicit in the docs.
I can see how knowing that a change to add FP barriers may be coming may affect designs. I believe Serge Pavlov mentioned that he was going to have to "rework" (his word) his patches since he didn't know about the restriction at all. So more information is probably better. I'll update after lunch.
Address review comment. Mention the possibility of the restrictions mentioned here changing in the future, but don't make any promises.
I think the consensus was that there is no good way to prevent hoisting of non-constrained FP arith ops, since they are side-effect free.
I don't see any benefit in mentioning that. I agree with Cameron that there is currently no good way to prevent hoisting, and I don't think we want for there to be a way to do that because an explicit goal of the constrained implementation was to ensure that it didn't interfere with optimization of code that didn't require any restrictions, which we believe will always be the majority case by a considerable margin. I expect that mixing of constrained and non-constrained regions will be rather rare. The use of intrinsics is the mechanism we've chosen to restrict code motion.
My understanding of our long term goal is that we will teach optimizations to handle the intrinsics, so that when optimizations are possible (within the constraints described by the intrinsic) they will be performed. Once we reach that state, there will be no serious downside to using an intrinsic with the most permissive settings versus a raw FP operation.
docs/LangRef.rst | ||
---|---|---|
15060 | As long as you're cleaning this up, I would suggest ditching the ordinal adjectives (which I never should have used in the original documentation as the problem you're fixing here should have been foreseeable). How about saying "the data operands and the return value" here and referring to "rounding mode argument" and "exception behavior" argument below. You can't really say "next" and "last" there since they aren't always both used. Some additional rewriting will be necessary to avoid saying "the rounding mode argument is a metadata argument specifying the rounding mode...." Here's a suggestion:
|
Incorporate changes and text requested by Andrew Kaylor. Remove mention of the lack of barriers and include text on how to accomplish mixing without barriers.
As long as you're cleaning this up, I would suggest ditching the ordinal adjectives (which I never should have used in the original documentation as the problem you're fixing here should have been foreseeable). How about saying "the data operands and the return value" here and referring to "rounding mode argument" and "exception behavior" argument below. You can't really say "next" and "last" there since they aren't always both used.
Some additional rewriting will be necessary to avoid saying "the rounding mode argument is a metadata argument specifying the rounding mode...." Here's a suggestion: