Need to fix Sphinx warnings

Thanks for updating this bit of documentation!

In D67360#1668007, @kpn wrote:

Address review comment. Mention the possibility of the restrictions mentioned here changing in the future, but don't make any promises.

It took some digging, but I finally found the e-mail thread where we initially agreed that we can't mix constrained FP intrinsics and non-constrained FP operations within a function. Here it is: http://lists.llvm.org/pipermail/cfe-dev/2017-August/055325.html

In D66092#1632642, @sepavloff wrote:

• What is the issue with moving a = b/c? If it moves ahead of if statement it seems OK, because the rounding mode is the same in that point. It cannot be moved inside the block (where rounding mode is different) because it breaks semantics.

In D66092#1630997, @sepavloff wrote:

Replacement of floating point operations with constrained intrinsics seems more an optimization helper then a semantic requirement. IR where constrained operations are mixed with unconstrained is still valid in sense of IR specification.

In D66092#1627339, @sepavloff wrote:

In D66092#1625380, @kpn wrote:

Also, if any constrained intrinsics are used in a function then the entire function needs to be constrained. Is this handled anywhere?

If we decided to make the entire function constrained, it should be done somewhere in IR transformations, because inlining may mix function bodies with different fp options.

In D62731#1623114, @mibintc wrote:

@andrew.w.kaylor Thanks Andy. Reminder -- in a private document you indicated to me that -fp-speculation=safe corresponds to the maytrap setting for the exception argument. This patch is implemented with those semantics.

I'm not entirely caught up on this review. I've only read the most recent comments, but I think I've got enough context to comment on the metadata arguments.

My understanding is that IEEE-754 requires us to produce an exception if and only if the exception would be produced by a literal interpretation of the source. However, it does not require that the exceptions be raised in the same order as implied by the source. Also, that's what the LLVM language reference says we'll do with "fpexcept.strict" -- "The number and order of floating-point exceptions is NOT guaranteed." So, I think the changes you've got here are correct.

In D64067#1568895, @hfinkel wrote:

One thing to realize about these flags is that they're ABI-altering flags. If the user provides the flag to alter the platform defaults, this only works if the user also ensures that matches the ABI of the relevant system libraries that the compiler is using (e.g., because the user is explicitly linking with a suitable libc).

In this review (https://reviews.llvm.org/D6260) @rsmith mentions that this should also have an effect on name mangling.

I might be opening a can of worms here and I'm not a language expert, but it isn't clear to me from reading the C99 standard that defining fptosi/fptoui as returning poison values in the unrepresentable case allows correct implementation of the C standard. That is, it doesn't seem to me that the standard actually says this is undefined behavior. It just says the resulting value is unspecified, and the exception behavior is explicitly defined. On the other hand, C++ does say clearly that it is undefined behavior, right?

For the constrained intrinsics, at least in the case where the exception semantics argument is "fpexcept.strict", we need to make sure the invalid exception is raised. If the exception semantics argument is "fpexcept.ignore" or "fpexcept.maytrap" we could allow the conversion to be optimized away.

In D43515#1548845, @kpn wrote:

I believe the speculative exceptions should be largely fixed by r348251, committed by rksimon. I changed the code to continue to use strict nodes when expanding a strict node. Since the strict nodes are chained, does that not solve the part of the problem not solved by r348251? Is the existing comment not enough, or do I need to copy some of the commit message into code comments?

How would you feel about rebooting this as a new patch? There's a lot of irrelevant history here, and I feel like I'm missing some context as I review it.

OK. I'm convinced. This should let us get a correct solution in place, and as you say we can add on something to handle rounding modes later if needed.

In D55506#1527992, @uweigand wrote:

In D55506#1527651, @andrew.w.kaylor wrote:

Why is the FPBarrierChain getting involved with the BarrierChain for memory objects? Even without this patch I think we might be entangling the strict FP nodes with other chained nodes more than we should.

The BarrierChain tracks calls, volatile/atomic memory accesses, and UnmodeledSideEffects. I do believe that FP exceptions must indeed be kept stable relative to those.

My patch does *not* entangle FP exceptions with regular memory accesses, which do *not* touch BarrierChain.

Why is the FPBarrierChain getting involved with the BarrierChain for memory objects? Even without this patch I think we might be entangling the strict FP nodes with other chained nodes more than we should.

Updated test case

I was also wondering if there has been any progress with this. Was there any more discussion on the ABI mailing list?

lgtm

I'm OK with this. Thanks for the TODO comment!

In D61331#1485000, @efriedma wrote:

We generally try to avoid keeping dead code in-tree, but I guess I'm not strongly opposed to it here.

Why wouldn't we want to reuse this code path?

Rather than get rid of this, can we update it to handle strict FP nodes correctly? Or at least put a skeleton in place to prepare to handle it correctly?

In D57504#1469847, @simoll wrote:

According to the LLVM langref, "fpexcept.ignore" seems to be the right option for exceptions whereas there is no "round.permissive" option for the rounding behavior. Abusing rmInvalid/ebInvalid seems hacky.

lgtm

I haven't had time to work on the alternate approach suggested, but one of my colleagues is working on it.

In D55506#1410052, @wuzish wrote:

Yes, the chain prevents redordering of floating point instructions by SelectionDAG. But it's fine to reorder instructions with static rounding mode(and ignore exception) and no need for chain. Because they do not have side effect, it means the result of such instructions only depend on input (eg, float add including source operands and mode encoding), does not depend on outside state variable that is current rounding mode. It also means the result is unchanged no matter how many times happens so long as the input is same.

For the record, I'm not sure about the previous decision that passing strings is too expensive. On the one hand, bisection is almost always disabled and is disabled in 100% of cases where anyone cares about compile time (though that may not be true of all opt gate use cases). On the other hand, even for a relatively large file with many functions and loops this is going to be on the order of 200,000 calls to this interface. Sure, building 200,000 strings isn't cheap, but in a compilation that's running 200,000 optimization passes it's minuscule.

I haven't had a lot more time to spend on this, but I did do a bit of investigation. I still only have a vague idea of what would be required to implement hard-coded offsets, but it didn't look to me like there is existing infrastructure for this so all of the things that just kind of magically worked with this patch (like growing the stack allocation and writing the .seh_savexmm directive) would need to be explicitly updated, right?

This is looking pretty good. I don't think I know the Selection DAG well enough to offer a proper review of that. I'll see if I can get Craig's attention on it.

This looks like a promising direction. I particularly like the idea of having a way to intersect information from the backend instruction definitions with the constraints coming from the IR. However, I also have some concerns.

I'm a bit out of my depth with the tablegen type handling stuff. I have some minor comments regarding naming consistency. Everything looks reasonable to me.

Looks good to me too.

Thanks for posting the incremental revision.

In D53157#1304895, @cameron.mcinally wrote:

The problem I was missing is when a FENV_ACCESS=OFF operation, like a FDIV, is hoisted into a FENV_ACCESS=ON region. I see it now, but still think that forcing FENV_ACCESS=OFF operations into constrained intrinsics is a big hammer. If there is a way to add barriers around function calls in a FENV_ACCESS=ON region, that would be better.

In D53157#1302724, @uweigand wrote:

A couple of comments on the previous discussion:

1. Instead of defining a new command line option, I'd prefer to use the existing options -frounding-math and -ftrapping-math to set the default behavior of math operations w.r.t. rounding modes and exception status. (For compatibility with GCC if nothing else.)

In D53157#1291978, @cameron.mcinally wrote:

In D53157#1291964, @kpn wrote:

I don't expect anyone would need to switch between constrained and regular floating point at an instruction level of granularity.

The Standard allows for this (to some degree). E.g. FENV_ACCESS can be toggled between nested compound statements.

Also, some AVX512 hardware instructions have explicit SAE and RM operands.

Agreed. Reverting this patch wouldn't move us forward on constrained FP handling. What I'm saying (and what I think @nastafev is saying) is that this patch is taking a built-in that allows the user to express specific signalling behavior and throwing away that aspect of its semantics. Granted we do say that FP environment access is unsupported, so technically unmasking FP exceptions or even reading the status flag is undefined behavior. But it seems like there's a pretty big difference between using that claim to justify enabling some optimization that might do constant folding in a way that assumes the default rounding mode versus using that claim to disregard part of the semantics of a built-in that is modeling a target-specific instruction.

In D45616#1290897, @nastafev wrote:

can trigger arbitrary floating-point exceptions anywhere in your code

I believe this statement reflects the current state of many compilers on the market, I guess I just don't see the reason why making things worse. It seems the original intent of the commit was to add support for masked compares, and that could have been achieved without breaking what already worked.

I hope the patch is ultimately helping some performance optimization, but it is breaking the original intent of some legitimate programs that worked before, and introduces correctness regression. So to me it must be at least guarded by a flip-switch.

The reference to constrained floating-point intrinsics work is relevant, but it will obviously take time and extra effort to enable and then to unbreak all the cases that are made broken here. Instead one could postpone lowering of the particular instructions until it was possible without violation of the semantics...

Craig Topper also raised some concerns with me (in person, his desk is right by mine) about the potential effect this might have on code size. He tells me that IRBuilder calls are intended to always be inlined and if we grow the implementation of these functions too much it could lead to noticeable bloat. It still seems to me like it might be worthwhile for the simplification it would allow in the front end, but I'm not really a front end guy so I definitely agree that we should get some input from front end people about what they want.

In D54121#1290989, @cameron.mcinally wrote:

compareSignalingGreaterEqual(a,b) is equivalent to compareSignalingLessUnordered(b, a)

I think my preference would be to have the predicate in the function name. I briefly toyed with the idea of hacking AsmWriter to print a constant integer as the corresponding predicate string, but I think that would look too weird. Also, I don't think we should open the door to something trying to use the value that represents the predicate as if it were a real value. In this sense the predicate argument, if we had one, should really be a token but I don't think we want to add new token constants just for this.

Rather than having separate methods to create the constrained versions of the intrinsics, why not have a way to set the constrained state in the IR builder and have the regular CreateFAdd et. al. functions use that to automatically create the constrained intrinsic versions? This would correspond to how fast math flags are handled.

This is definitely a tricky case. I don't really like any of the available solutions. I'll try to think more about it, and maybe someone else will have a brilliant suggestion.

This looks good, except that I assume now you'll be removing the FMA checks from the tests.

lgtm

In D43142#1285856, @cameron.mcinally wrote:

I think we both agree that it's undefined behavior. If that's correct, then it doesn't really matter what we do after we hit it. So any solution is acceptable...

In D43142#1285789, @cameron.mcinally wrote:

In D43142#1285708, @andrew.w.kaylor wrote:

The only thing we need to worry about is making sure that FP operations don't migrate across calls or other FP operations that would break these semantics. Using the intrinsics after inlining takes care of that.

I don't agree with this. This is changing the semantics if we choose to inline a function by converting some operations into constrained intrinsics. In other words, an executable will have different behavior if we choose to inline or not. That's not ok.

In D43142#1285602, @cameron.mcinally wrote:

In D43142#1285565, @kpn wrote:

If all optimizations including constant folding, or at least optimizations on floating point, are delayed until after inlining then there's no problem.

I'll add that this is a ton of work. A binary Instruction can't currently have two Constant operands. So, ConstantFolding is baked into the Instruction implementation right now. If I'm mistaken, someone please correct me.

I'm not an expert on inlining, but I imagine there are challenges moving it to 1st in the pass order too. I could see it being difficult to analyze cost on an unoptimized, non-canonical IR.

In D43142#1285069, @cameron.mcinally wrote:

I'm realizing that FENV_ACCESS is poorly designed.

In D43142#1284800, @hfinkel wrote:

In D43142#1284271, @cameron.mcinally wrote:

In D43142#1284190, @kpn wrote:

...

It's unclear to me how LTO (or other cross file inlining) would work here. I haven't given it much though until now. My knee-jerk reaction is that we shouldn't be inlining from a FENV_ACCESS=OFF to FENV_ACCESS=ON location.

I'm pretty sure that we decided that we couldn't (because once you inline the regular FP ops, there's no way to restrict their movement relative to the constrained intrinsics at the IR level).

In D53678#1275140, @erik.pilkington wrote:

FYI: this will be fixed by https://reviews.llvm.org/D53538 when that lands.

Can you update this review with a summary that describes the problem your are trying to fix by disabling instruction sinking here?

In D50913#1245120, @cameron.mcinally wrote:

There hasn't been any strong objects, but I haven't seen many strong accepts either besides the few main stakeholders. I'm under the assumption that silence is a passive reject in situations like this.

Should I keep pushing for it? It felt like I was beating a dead horse...

In D50913#1211409, @arsenm wrote:

This is more a question of lowering and not an IR semantics question. The fneg will be defined as having no side effects or trapping. If through some architectural specific quirk the expected instructions need something more to avoid this, then that is their issue to deal with. Since it should always be impleentable with bitwise operations, this shouldn't be an issue

In D50913#1209179, @cameron.mcinally wrote:

Your argument here is compelling. If there's no guarantee that an FSUB and FNEG are disjoint, then this won't work. Although, an FSUB and FNEG aren't really the same operation. Perhaps we should only be doing the transformation under UnsafeMath conditions to begin with...

I feel like it might be a bad idea to have floating point instructions that don't have constrained forms.

Fair enough.

I hope I'm not coming across as too argumentative here. I don't really have strong feelings about this function pointer type patch and ultimately I see that you are right, but the objections you are raising here would equally apply to what I'm working on with the IR linker and if I find a way to fix that, I'll care a bit more about that case. (If you'd like a preview, here's the bug I'm trying to fix: https://bugs.llvm.org/show_bug.cgi?id=38408)

The LLVM linker also seems to have a bunch of problems with resolving pointer types in structures. I'm looking into a couple of those now.