Previously we only checked this if the arguments had the attributes, but
not if the callee had the attributes.
As examples, there are a number of tests missing attributes on calls.
Paths
| Differential D101725
[Verifier] Check that calls' arguments match the callee's byval/inalloca/preallocated AbandonedPublic Authored by aeubanks on May 2 2021, 1:04 PM.
Details
Diff Detail
Unit TestsFailed Event TimelineHerald added subscribers: dexonsmith, okura, kuter and 2 others. · View Herald TranscriptMay 2 2021, 1:04 PM Comment Actions Though does this break bitcode backwards compatibility, or does the bitcode not have this ambiguity/duplication? While the textual IR doesn't have backcompat issues - maybe it'd be easy enough for the textual IR parser to correct this issue by checking the declaration and attaching the right attribute value? Though not necessary by any means.
Herald added subscribers: kerbowa, aheejin, jgravelle-google and 4 others. · View Herald TranscriptMay 2 2021, 5:24 PM Comment Actions I think the bitcode and textual representation both allow this issue. Comment Actions
The argument is that this was always invalid, but a bug that it wasn't detected, so it doesn't need to be upgraded when reading IR, it's OK for that to fail the verifier) Compared to an argument that it was valid, is now invalid, so needs to be upgraded to ensure bitcode compatibility? Do you think it'd be especially complicated to auto-upgrade? Comment Actions FWIW I think the that we don't auto-upgrade textual IR as a matter of general policy. The only exception that comes to mind are align annotations on load/store, and those are really more a matter of the annotation being optional in textual IR than a real auto-upgrade. Comment Actions
Yeah my argument is that it was always invalid. I'm sure it's possible to auto-upgrade bitcode, but that would have non-zero cost for every call we read from bitcode. IMO it's not worth it if this was always supposed to be invalid. Maybe we should ask llvm-dev for more opinions? Comment Actions I need more time to read into this, but my first thought is, we can't do this. People can write code that does stuff like: struct Byval { int x; } bv; void takeByval(Byval); void foo(bool isByRef, void (*fp)()) { if (isByRef) { ((void(*)(ByVal*))fp)(&bv); } else { ((void(*)(ByVal))fp)(bv); } } void bar() { foo(false, &takeByval); } Inlining foo into bar and simplifying would lead to a verifier failure, no? This is for example why the verifier doesn't check that calling conventions match: Comment Actions
Yeah - if it's not possible to make that sort of IR from the APIs - if it'd require hand-crafted textual IR, or really weird/novel bitcode creation (please confirm whether/how hard it would be to have this in bitcode - if simple use of the IRBuilder/IR creation APIs could result in this problematic representation) I'd probably be OK calling it an "accepts invalid" bug and declaring it invalid. Pending @rnk's concerns too.
Revision Contents
Diff 342263 llvm/lib/IR/Verifier.cpp
llvm/test/CodeGen/X86/movtopush.ll
llvm/test/Transforms/ArgumentPromotion/dbg.ll
llvm/test/Transforms/ArgumentPromotion/fp80.ll
llvm/test/Transforms/Attributor/ArgumentPromotion/dbg.ll
llvm/test/Transforms/Attributor/ArgumentPromotion/fp80.ll
llvm/test/Transforms/Attributor/readattrs.ll
llvm/test/Transforms/Attributor/value-simplify.ll
llvm/test/Transforms/TailCallElim/basic.ll
llvm/test/Verifier/indirect-attrs.ll
|
Should this be in a separate patch? (looks not strictly related/required in this patch)