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

[David Blaikie]

On Mon, Mar 30, 2015 at 10:47 AM, 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.
>

FWIW ArgPromo and DAE are both setup to null out the llvm::Function
pointers in this case - so as to ensure debug info no longer describes the
function in such a way that a debugger might try to call it or print its
arguments, etc. (there's no way in DWARF to describe the original type
while telling the debugger to call the function in a different way
(omitting arguments, etc) and we haven't taught LLVM about how to omit the
location of certain variables, I don't think - maybe that bit just works?)

so I'm not sure which optimizations are creating this bitcast & not nulling
out the MDSubprogram's llvm::Function* - but I /think/ whenever that is
happening, it's a bug.

- David


>
>
> - 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/2c869771/attachment.html>