[llvm-dev] [llvm-reduce] Reduction to undef/poison/null? (original) (raw)

Arthur Eubanks via llvm-dev llvm-dev at lists.llvm.org
Mon Aug 30 11:36:27 PDT 2021

I frequently use llvm-reduce just to minimize a crash caused by some change and present that to the author of a change to look at. I don't think that having tons of freeze poisons in a repro file is nice to work with. If a crash repros with a 0 as opposed to a freeze poison the 0 seems much more appealing to present.

We could add a flag to reduce to the various options here if people have different needs.

On Mon, Aug 30, 2021 at 11:31 AM Johannes Doerfert via llvm-dev < llvm-dev at lists.llvm.org> wrote:

On 8/30/21 1:22 PM, Roman Lebedev via llvm-dev wrote: > I've been thinking we should be using freeze poison, > but i don't think this question matters for the patch at hand, > it should just stick to the current practice of using undef.

I like freeze poison. It conveys the idea w/o making things UB all the time. It basically is an oracle w/o the side effects. FWIW, when I ported tests to the Attributor, e.g., from ArgumentPromotion or IPSCCP, I had to manually remove all the UB that made the test meaningless first. In general, tests that contain statically provable UB are less likely to be meaningful over time and/or be reusable. ~ Johannes

> Roman. > > On Mon, Aug 30, 2021 at 9:14 PM Florian Hahn via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> >> >>> On 30 Aug 2021, at 19:59, David Blaikie via llvm-dev <_ _llvm-dev at lists.llvm.org> wrote: >>> >>> Nicer because it's less likely to introduce new UB? Or some other reason? >>> >> Using undef/poison is problematic, because there are multiple ways this could cause new UB (e.g. branch on undef, passing poison/undef to a function with a noundef argument). >> >> I’m not sure if using zero will work well in certain cases, because it can introduce UB as well (e.g. load from null, passing as nonnull argument). >> >> I think ideally we would have a way to materialise values we know nothing about, but are not undef. Perhaps we could add some oracle function, but that would come with its own drawbacks. >> >> Cheers, >> Florian >> _>> ________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev _> ________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev -- ────────────────────── ∽ Johannes Doerfert ∽ ∽ Pronouns: he/him ∽ ∽ Researcher @ ANL ∽

LLVM Developers mailing list llvm-dev at lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210830/e5b54fe8/attachment.html>

More information about the llvm-dev mailing list