Johannes Doerfert via llvm-dev
2021-Aug-30 18:31 UTC
[llvm-dev] [llvm-reduce] Reduction to undef/poison/null?
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 ∽
Arthur Eubanks via llvm-dev
2021-Aug-30 18:36 UTC
[llvm-dev] [llvm-reduce] Reduction to undef/poison/null?
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>