Allow specialization of functions with "dynamic" denormal modes to a
known IEEE or DAZ mode based on callers. This should make it possible
to implement a is-denormal-flushing-enabled test using
llvm.canonicalize and have it be free after LTO.
Details
Diff Detail
Event Timeline
Remove assumed, nothing ever changes and stop tracking invalid f32 state, only consider that during manifest
llvm/include/llvm/Transforms/IPO/Attributor.h | ||
---|---|---|
5173 | Is it correct to say that an optimistic fix point is when all the "dynamic" components are set to default (ieee)? This attribute is reinventing what a fixed point means. Does this function need to set the optimistic fixed point? Or I would guess this function is actually never called, in which case it should be marked with llvm_unreachable()? | |
5177 | Another theoretical issue with what a fixed point means for this attribute. Is there any sequence of actions where this function is called followed by something that depends on isAtFixpoint()? |
llvm/lib/Transforms/IPO/AttributorAttributes.cpp | ||
---|---|---|
9023 | This is why I am saying that the optimistic fixed point is to replace dynamic with default. It may be wrong to "assume" default, but that's different from the optimistic fixed point. |
llvm/include/llvm/Transforms/IPO/Attributor.h | ||
---|---|---|
5173 | No. You cannot say IEEE is more optimistic than preserve-sign or positive-zero. They're just different. The only thing you can infer is known or unknown |
llvm/include/llvm/Transforms/IPO/Attributor.h | ||
---|---|---|
5173 | I understand what you want it to do. I am trying to understand what the code actually means. The manifest function replaces "dynamic" with "default/ieee". Both the optimistic and pessimistic fixed points leave dynamic alone. What is a fixed point here? When a client calls either of the fixed point functions, what should the interpretation of "dynamic" be? Should it be the same as the manifest method, which means setting it to default/ieee? Clearly, the client intended that no more changes should be possible, but the manifest will change it. |
llvm/include/llvm/Transforms/IPO/Attributor.h | ||
---|---|---|
5173 | Or to put it in more concrete terms, is it okay that either of the following patterns, if it occurs, can potentially fire the assert? indicateOptimisticFixpoint(); assert(isAtFixpoint()); and indicatePessimisticFixpoint(); assert(isAtFixpoint()); |
llvm/include/llvm/Transforms/IPO/Attributor.h | ||
---|---|---|
5173 | I believe isValidState is supposed to protect from this, combined with going to invalid for combinations that don't make sense. Combinations that don't make sense go to invalid and then should be ignored |
llvm/include/llvm/Transforms/IPO/Attributor.h | ||
---|---|---|
5173 | I am sorry I don't follow that at all. The attribute has a definition for a fixed point. I understand setting nonsensical combinations to invalid state, but the set-fixed-point functions neither set the invalid state, nor some state that satisfies isAtFixPoint(). Then how are the above asserts prevented? Taking a step back, I am not opposed to the goal being achieved here, but I am not seeing how it fits the apparent design of the Attributor. Should this attribute set a new precedent for what a fixed point means? I would rather defer to others who are more familiar with the original intention of the Attributor. |
llvm/include/llvm/Transforms/IPO/Attributor.h | ||
---|---|---|
5161 | Some of my earlier comments are wrong, because I misunderstood the part about dynamic modes. But here's what I think needs to be consistent with the notion of a fixed point. The update() calls this function to check if it should attempt a refinement in yet another iteration. But the updateImpl() function tries to indicate when a fixed point is reached, which is when it is unable to follow through all the callsites anymore. There's a loss of information about whether future iterations should call updateImpl() again, because indicatePessimisticFixpoint() doesn't change any state. In that case, maybe the state of this Attribute should really be a single bool called AtFixpoint? Then both optimistic and pessimistic calls set it to true, and return UNCHANGED, while isAtFixpoint() returns the current value of this bool. Also, the introductory comments in Attributor.h should be updated to say that the Known/Assumed scheme is the most common, but not the only way to represent fixed points. |
Use explicit bool for fixpoint like SetState.
Also I tried adding this to attributor-light which apparently will require more work than just adding the ID to the allowed set
llvm/include/llvm/Transforms/IPO/Attributor.h | ||
---|---|---|
5161 |
That's what SetState does, I can just copy that | |
llvm/lib/Transforms/IPO/AttributorAttributes.cpp | ||
9014 | This case seems interesting. The other attributes seem to not do that, but it does appear to fire |
llvm/include/llvm/Transforms/IPO/Attributor.h | ||
---|---|---|
5152–5155 | It turns out moving this to handle the invalid mode at initialize broke the partially dynamic mode case from a fixed caller (and my test for that was accidentally dead and deleted). At this point I'll fix that separately if it matters |
llvm/include/llvm/Transforms/IPO/Attributor.h | ||
---|---|---|
5152–5155 | And by if it matters, I mean it doesn't now because the libraries are compiled with full denormal-fp-math=dynamic. We probably should refine that to only the f32, because the f64/f16 flushing probably does not work in practice |
LGTM, with a few nits.
llvm/include/llvm/Transforms/IPO/Attributor.h | ||
---|---|---|
5114–5116 | The usual way is to just invert the == operator? | |
6317–6320 | Is this just a quirk of how Phab displays the diff? Or the new struct started at the wrong point? | |
llvm/lib/Transforms/IPO/AttributorAttributes.cpp | ||
8988 | Did you mean "callee"? |
llvm/include/llvm/Transforms/IPO/Attributor.h | ||
---|---|---|
5114–5116 | I will never understand why C++ doesn't do this for you | |
5152–5155 | I looked at this again and the case that regressed is invalid, we just now get worse handling of invalid cases which is not interesting | |
6317–6320 | I think this is a consequence of diffs based on multiple starting points. On the last rebase a few new AAs showed up and pushed this further down the file Plus the operator<< here was misplaced to begin with, it should be moved elsewhere |
Make it clear this is for string attributes, maybe even just pass the string keys.