Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Surgical fix for bad assertion generation #55626

Merged
merged 3 commits into from
Jul 15, 2021
Merged

Surgical fix for bad assertion generation #55626

merged 3 commits into from
Jul 15, 2021

Commits on Jul 14, 2021

  1. Add a test

    @SingleAccretion
    SingleAccretion committed Jul 14, 2021
    Configuration menu
    Copy the full SHA
    5c7fab2 View commit details
    Browse the repository at this point in the history

  2. Surgical fix for bad assertion generation 

    Say we have a cast like this: CAST(uint <- long).
What value does this tree compute?
[int.MinValue..int.MaxValue] - IR operates on signed TYP_INTs.
But assertion prop generated [0..uint.MaxValue] for it.

The confusion created by this "how to interpret TYP_UINT" question
caused a bug where for the assertion generated for the above cast,
in the form of [0..uint.MaxValue], propagation could remove
a checked cast in the form of CAST_OVF(uint < int).

The proper fix is to generate proper ranges for such casts.

The surgical fix proposed here is to always treat casts to TYP_UINT
as if they were to TYP_INT. This is conservative, but always correct.
The generated assertion is useless of course, but that makes this a
zero-diff change.
    @SingleAccretion
    SingleAccretion committed Jul 14, 2021
    Configuration menu
    Copy the full SHA
    56c0983 View commit details
    Browse the repository at this point in the history

  3. Add a comment explaining the quirk

    @SingleAccretion
    SingleAccretion committed Jul 14, 2021
    Configuration menu
    Copy the full SHA
    3c04b13 View commit details
    Browse the repository at this point in the history