[dynamo] graph break on const dict KeyError

[williamwen42]

Stack from ghstack (oldest at bottom):

• [dynamo] fix https://github.com/pytorch/pytorch/issues/93624 #125945
• [dynamo] graph break on issubclass call with non-const args #125943
• -> [dynamo] graph break on const dict KeyError #125882

Fixes #125866

cc @voznesenskym @penguinwu @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv @jiayisunx @chenyang78 @kadeng @chauhang

[pytorch-bot]

🔗 Helpful Links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/125882

• 📄 Preview Python docs built from this PR
• 📄 Preview C++ docs built from this PR
• ❓ Need help or want to give feedback on the CI? Visit the bot commands wiki or our office hours

Note: Links to docs will display an error until the docs builds have been completed.

✅ No Failures

As of commit 20b4ba9 with merge base 1966612 ():
💚 Looks good so far! There are no failures yet. 💚

This comment was automatically generated by Dr. CI and updates every 15 minutes.

[jansel]

What error is this catching? I worry this will be hiding bugs.

[williamwen42]

This is catching an error on from a python call - fn would be a builtin function. Idea is that if we get a python error when trying to constant fold, we bubble up the error to skip the frame, then we evaluate the frame as normal, which would result in the same error. In the case of the repro, we would be catching a KeyError.

[jansel]

Let's make catch case more narrow, perhaps by checking the message and warning if it is somthing else.

[williamwen42]

I think that any possible exception raised by a function in _constant_fold_functions would have to be caught, e.g. KeyError, ZeroDivisionError, AttributeError, ValueError, etc. We could determine a list of allowed exceptions (by going through the builtin constant fold op list and manually checking for exceptions that could be raised), but if we miss any, then tracing any code like below would crash:

def fn(x):
    try:
        y = ... # builtin constant fold op with constants that raises an exception we missed
        # e.g. we forgot ZeroDivisionError for y = 1 / 0
    except Exception:
        y = 1
    return x + y

What kind of bugs do you think would be hidden? My intent here is that if running the builtin op results in an exception, we should skip the frame, then default evaluation will also raise the exception and run any exception handlers.

[jansel]

Let's make catch case more narrow, perhaps by checking the message and warning if it is somthing else.