This is an archive of the discontinued LLVM Phabricator instance.

Attributor: Try to propagate concrete denormal-fp-math{-f32}
ClosedPublic

Authored by arsenm on Jul 24 2023, 7:38 AM.

Details

Summary

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.

Diff Detail

Event Timeline

arsenm created this revision.Jul 24 2023, 7:38 AM
Herald added a project: Restricted Project. · View Herald TranscriptJul 24 2023, 7:38 AM
arsenm requested review of this revision.Jul 24 2023, 7:38 AM
Herald added a project: Restricted Project. · View Herald TranscriptJul 24 2023, 7:38 AM
Herald added a subscriber: wdng. · View Herald Transcript
jdoerfert added inline comments.Jul 25 2023, 9:33 AM
llvm/include/llvm/Transforms/IPO/Attributor.h
1921

Make it clear this is for string attributes, maybe even just pass the string keys.

llvm/lib/Transforms/IPO/AttributorAttributes.cpp
8987

Assumed should be more optimistic, this is a fix point, we'll never call update(Impl)

arsenm added inline comments.Jul 25 2023, 9:34 AM
llvm/lib/Transforms/IPO/AttributorAttributes.cpp
8987

There isn't really an optimistic vs. not choice. There's only do we know or not, you can't declare one of the modes better than the other

8987

The isFixpoint is more sophisticated than known == assumed

arsenm updated this revision to Diff 544434.Jul 26 2023, 10:44 AM
arsenm marked an inline comment as done.

Remove assumed, nothing ever changes and stop tracking invalid f32 state, only consider that during manifest

sameerds added inline comments.Jul 27 2023, 2:13 AM
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()?

sameerds added inline comments.Jul 27 2023, 11:11 PM
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.

arsenm added inline comments.Jul 28 2023, 11:22 AM
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

sameerds added inline comments.Jul 29 2023, 9:49 PM
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.

sameerds added inline comments.Jul 30 2023, 11:27 PM
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());
arsenm added inline comments.Jul 31 2023, 5:03 PM
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

sameerds added inline comments.Aug 4 2023, 1:34 AM
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.

arsenm updated this revision to Diff 548011.Aug 7 2023, 6:11 PM

Remove dead code

sameerds added inline comments.Aug 7 2023, 11:12 PM
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.

sameerds added inline comments.Aug 7 2023, 11:21 PM
llvm/lib/Transforms/IPO/AttributorAttributes.cpp
8989

If all modes are non-dynamic, should this set optimistic fixed point?

9014

If all modes are "not dynamic", should this call optimistic fixpoint?

arsenm updated this revision to Diff 554677.Aug 30 2023, 5:53 AM
arsenm marked 2 inline comments as done.

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

In that case, maybe the state of this Attribute should really be a single bool called AtFixpoint?

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

arsenm added inline comments.Aug 30 2023, 6:59 AM
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

arsenm added inline comments.Aug 30 2023, 7:01 AM
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

arsenm updated this revision to Diff 554700.Aug 30 2023, 7:01 AM
sameerds accepted this revision.Aug 30 2023, 11:52 PM

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"?

This revision is now accepted and ready to land.Aug 30 2023, 11:52 PM
arsenm marked 2 inline comments as done.Aug 31 2023, 5:24 AM
arsenm added inline comments.
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