[llvm] r233562 - Verifier: Loosen r233559 check for 'function:' field in MDSubprogram

[David Blaikie]

On Mon, Mar 30, 2015 at 11:14 AM, Duncan P. N. Exon Smith <
dexonsmith at apple.com> wrote:

>
> > On 2015-Mar-30, at 11:03, David Blaikie <dblaikie at gmail.com> wrote:
> >
> >
> >
> > On Mon, Mar 30, 2015 at 11:00 AM, Duncan P. N. Exon Smith <
> dexonsmith at apple.com> wrote:
> >
> > > On 2015-Mar-30, at 10:47, David Blaikie <dblaikie at gmail.com> wrote:
> > >
> > >
> > >
> > > On Mon, Mar 30, 2015 at 10:45 AM, Duncan P. N. Exon Smith <
> dexonsmith at apple.com> wrote:
> > >
> > > > On 2015-Mar-30, at 10:39, David Blaikie <dblaikie at gmail.com> wrote:
> > > >
> > > >
> > > >
> > > > On Mon, Mar 30, 2015 at 10:04 AM, Duncan P. N. Exon Smith <
> dexonsmith at apple.com> wrote:
> > > > Author: dexonsmith
> > > > Date: Mon Mar 30 12:04:06 2015
> > > > New Revision: 233562
> > > >
> > > > URL: http://llvm.org/viewvc/llvm-project?rev=233562&view=rev
> > > > Log:
> > > > Verifier: Loosen r233559 check for 'function:' field in MDSubprogram
> > > >
> > > > Stop worrying about what the `function:` field is in `MDSubprogram`,
> > > > since it could be a bitcast [1].  Just check its type and leave it at
> > > > that.
> > > >
> > > > [1]:
> http://lab.llvm.org:8080/green/job/clang-stage2-configure-Rlto_build/3540/
> > > >
> > > > Is this an acceptable thing? How does this arise? Could we have a
> small test case demonstrating it? (and/or demonstrating how it comes about?)
> > >
> > > I think it's from function merging, so we needed bitcasts from one
> > > function type to the other.
> > >
> > > Once your opaque pointer type work is complete, those bitcasts won't
> > > be necessary, so we can check that it's pointing at a `Function`.
> > >
> > > Maybe I can use `stripPointerCasts()` to do that even now?
> > >
> > > My concern is that since the function type has changed, we probably
> shouldn't be describing it in the debug info anymore - if the debugger
> tries to call it, it'll be using the function type described in the debug
> info which will no longer match the implementation... that seems... bad.
> >
> > Ah, I see.  I think this only happens if the functions have compatible
> > types.  After your opaque pointer type work, I think it will only happen
> > if the functions have the same type.
> >
> > In this case, the `function`: field looked like this:
> >
> > void (%"class.llvm::UnaryInstruction.2113"*, %"class.llvm::Value.2107"*,
> %"class.llvm::Value.2107"*, %"class.llvm::Value.2107"*)*
> > bitcast (
> > void (%"class.llvm::TerminatorInst.4946"*, %"class.llvm::Value"*,
> %"class.llvm::Value"*, %"class.llvm::Value"*)*
> @_ZN4llvm10SelectInst4initEPNS_5ValueES2_S2_ to
> > void (%"class.llvm::UnaryInstruction.2113"*, %"class.llvm::Value.2107"*,
> %"class.llvm::Value.2107"*, %"class.llvm::Value.2107"*)*)
> >
> > This was effectively a bitcast from:
> >
> >     void (*) (UnaryInstruction*, Value*, Value*, Value*)
> >
> > to:
> >
> >     void (*) (TerminatorInst*, Value*, Value*, Value*)
> >
> > These function signatures are compatible because they're all pointers.
> >
> > After your work, they'll each have four `ptr` arguments, so they'll have
> > the same type.
> >
> > Given that, do you still think there's something to look into here
> > (besides possibly checking for a function in `stripPointerCasts()`)?
> >
> > Sounds plausible. I wouldn't mind knowing the optimization that's doing
> this, though - as I don't know what else it's doing to the implementation
> of the function or the caller... that still sounds like it's changed the
> signature/implementation of the function, possibly, even if the type
> happens to remain the same-ish.
> >
>
> lib/Transforms/IPO/MergeFunctions.cpp
>
> I'm looking at it right now myself to check my assertions above ;).
>

Thanks!

My cursory glance seems like it's correct (& will be simplified by my
opaque pointer work).


>
> > - David
> >
> >
> > >
> > > >
> > > >
> > > >
> > > > Modified:
> > > >     llvm/trunk/lib/IR/Verifier.cpp
> > > >
> > > > Modified: llvm/trunk/lib/IR/Verifier.cpp
> > > > URL:
> http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/IR/Verifier.cpp?rev=233562&r1=233561&r2=233562&view=diff
> > > >
> ==============================================================================
> > > > --- llvm/trunk/lib/IR/Verifier.cpp (original)
> > > > +++ llvm/trunk/lib/IR/Verifier.cpp Mon Mar 30 12:04:06 2015
> > > > @@ -846,9 +846,8 @@ void Verifier::visitMDSubprogram(const M
> > > >      auto *FMD = dyn_cast<ConstantAsMetadata>(RawF);
> > > >      auto *F = FMD ? FMD->getValue() : nullptr;
> > > >      auto *FT = F ? dyn_cast<PointerType>(F->getType()) : nullptr;
> > > > -    Assert(F && (isa<Function>(F) || isa<ConstantPointerNull>(F))
> && FT &&
> > > > -               isa<FunctionType>(FT->getElementType()),
> > > > -           "invalid function", &N, F);
> > > > +    Assert(F && FT && isa<FunctionType>(FT->getElementType()),
> > > > +           "invalid function", &N, F, FT);
> > > >    }
> > > >    if (N.getRawTemplateParams()) {
> > > >      auto *Params = dyn_cast<MDTuple>(N.getRawTemplateParams());
> > > >
> > > >
> > > > _______________________________________________
> > > > llvm-commits mailing list
> > > > llvm-commits at cs.uiuc.edu
> > > > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
> > > >
> > >
> > >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150330/e189005a/attachment.html>