<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 30, 2015 at 11:14 AM, Duncan P. N. Exon Smith <span dir="ltr"><<a href="mailto:dexonsmith@apple.com" target="_blank">dexonsmith@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
> On 2015-Mar-30, at 11:03, David Blaikie <<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>> wrote:<br>
><br>
><br>
><br>
> On Mon, Mar 30, 2015 at 11:00 AM, Duncan P. N. Exon Smith <<a href="mailto:dexonsmith@apple.com">dexonsmith@apple.com</a>> wrote:<br>
><br>
> > On 2015-Mar-30, at 10:47, David Blaikie <<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>> wrote:<br>
> ><br>
> ><br>
> ><br>
> > On Mon, Mar 30, 2015 at 10:45 AM, Duncan P. N. Exon Smith <<a href="mailto:dexonsmith@apple.com">dexonsmith@apple.com</a>> wrote:<br>
> ><br>
> > > On 2015-Mar-30, at 10:39, David Blaikie <<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>> wrote:<br>
> > ><br>
> > ><br>
> > ><br>
> > > On Mon, Mar 30, 2015 at 10:04 AM, Duncan P. N. Exon Smith <<a href="mailto:dexonsmith@apple.com">dexonsmith@apple.com</a>> wrote:<br>
> > > Author: dexonsmith<br>
> > > Date: Mon Mar 30 12:04:06 2015<br>
> > > New Revision: 233562<br>
> > ><br>
> > > URL: <a href="http://llvm.org/viewvc/llvm-project?rev=233562&view=rev" target="_blank">http://llvm.org/viewvc/llvm-project?rev=233562&view=rev</a><br>
> > > Log:<br>
> > > Verifier: Loosen r233559 check for 'function:' field in MDSubprogram<br>
> > ><br>
> > > Stop worrying about what the `function:` field is in `MDSubprogram`,<br>
> > > since it could be a bitcast [1].  Just check its type and leave it at<br>
> > > that.<br>
> > ><br>
> > > [1]: <a href="http://lab.llvm.org:8080/green/job/clang-stage2-configure-Rlto_build/3540/" target="_blank">http://lab.llvm.org:8080/green/job/clang-stage2-configure-Rlto_build/3540/</a><br>
> > ><br>
> > > 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?)<br>
> ><br>
> > I think it's from function merging, so we needed bitcasts from one<br>
> > function type to the other.<br>
> ><br>
> > Once your opaque pointer type work is complete, those bitcasts won't<br>
> > be necessary, so we can check that it's pointing at a `Function`.<br>
> ><br>
> > Maybe I can use `stripPointerCasts()` to do that even now?<br>
> ><br>
> > 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.<br>
><br>
> Ah, I see.  I think this only happens if the functions have compatible<br>
> types.  After your opaque pointer type work, I think it will only happen<br>
> if the functions have the same type.<br>
><br>
> In this case, the `function`: field looked like this:<br>
><br>
> void (%"class.llvm::UnaryInstruction.2113"*, %"class.llvm::Value.2107"*, %"class.llvm::Value.2107"*, %"class.llvm::Value.2107"*)*<br>
> bitcast (<br>
> void (%"class.llvm::TerminatorInst.4946"*, %"class.llvm::Value"*, %"class.llvm::Value"*, %"class.llvm::Value"*)* @_ZN4llvm10SelectInst4initEPNS_5ValueES2_S2_ to<br>
> void (%"class.llvm::UnaryInstruction.2113"*, %"class.llvm::Value.2107"*, %"class.llvm::Value.2107"*, %"class.llvm::Value.2107"*)*)<br>
><br>
> This was effectively a bitcast from:<br>
><br>
>     void (*) (UnaryInstruction*, Value*, Value*, Value*)<br>
><br>
> to:<br>
><br>
>     void (*) (TerminatorInst*, Value*, Value*, Value*)<br>
><br>
> These function signatures are compatible because they're all pointers.<br>
><br>
> After your work, they'll each have four `ptr` arguments, so they'll have<br>
> the same type.<br>
><br>
> Given that, do you still think there's something to look into here<br>
> (besides possibly checking for a function in `stripPointerCasts()`)?<br>
><br>
> 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.<br>
><br>
<br>
</div></div>lib/Transforms/IPO/MergeFunctions.cpp<br>
<br>
I'm looking at it right now myself to check my assertions above ;).<br></blockquote><div><br>Thanks!<br><br>My cursory glance seems like it's correct (& will be simplified by my opaque pointer work).<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
> - David<br>
><br>
><br>
> ><br>
> > ><br>
> > ><br>
> > ><br>
> > > Modified:<br>
> > >     llvm/trunk/lib/IR/Verifier.cpp<br>
> > ><br>
> > > Modified: llvm/trunk/lib/IR/Verifier.cpp<br>
> > > URL: <a href="http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/IR/Verifier.cpp?rev=233562&r1=233561&r2=233562&view=diff" target="_blank">http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/IR/Verifier.cpp?rev=233562&r1=233561&r2=233562&view=diff</a><br>
> > > ==============================================================================<br>
> > > --- llvm/trunk/lib/IR/Verifier.cpp (original)<br>
> > > +++ llvm/trunk/lib/IR/Verifier.cpp Mon Mar 30 12:04:06 2015<br>
> > > @@ -846,9 +846,8 @@ void Verifier::visitMDSubprogram(const M<br>
> > >      auto *FMD = dyn_cast<ConstantAsMetadata>(RawF);<br>
> > >      auto *F = FMD ? FMD->getValue() : nullptr;<br>
> > >      auto *FT = F ? dyn_cast<PointerType>(F->getType()) : nullptr;<br>
> > > -    Assert(F && (isa<Function>(F) || isa<ConstantPointerNull>(F)) && FT &&<br>
> > > -               isa<FunctionType>(FT->getElementType()),<br>
> > > -           "invalid function", &N, F);<br>
> > > +    Assert(F && FT && isa<FunctionType>(FT->getElementType()),<br>
> > > +           "invalid function", &N, F, FT);<br>
> > >    }<br>
> > >    if (N.getRawTemplateParams()) {<br>
> > >      auto *Params = dyn_cast<MDTuple>(N.getRawTemplateParams());<br>
> > ><br>
> > ><br>
> > > _______________________________________________<br>
> > > llvm-commits mailing list<br>
> > > <a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a><br>
> > > <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
> > ><br>
> ><br>
> ><br>
<br>
</div></div></blockquote></div><br></div></div>