[llvm-dev] What does it mean by a "DICompileUnit missing from llvm.dgs.cu" ? | Where is the error ?
SANJAY SRIVALLABH SINGAPURAM via llvm-dev
llvm-dev at lists.llvm.org
Sun Mar 12 23:07:55 PDT 2017
Hello,
I enabled "-polly-dump-before -polly-dump-after" to obtain the IR before
and after Polly. Have attached kernel_gemm-before.ll (kg_before.ll) and
kernel_gemm-after.ll (kg_after.ll)
observations,
- Both kg_before.ll and kg_after.ll have,
- The only DICompileUnit is at !2
- !llvm.dbg.cu=!{!2}
- I don't think Julia is generating incorrect debug info .
- For opt kernel_gemm-before.ll $FLAG -o output.ll
- All the following FLAGs except "-O3 -polly -polly-target=gpu"
didn't have a problem with the Module,
- -O3 -polly -polly-target=cpu
- -O3
- The only time verifyModule is called within Polly is at
kernerlFinalize.
- This could mean that Polly's generating the wrong debug info,
which is uncovered only when GPU code's generated.
- I'm not sure if verifyModule is called indirectly when
-polly-target=cpu
- Or, the debug information is corrupted when sending or/and
receiving information to/from PPCG.
- For opt output.ll -O3 -polly -polly-target=gpu -o
output.output.ll, where output.ll generated by opt kg_before.ll -O3 -polly
-polly-target=cpu,
- verifyModule is involed thrice, but issues the same error
- Possibly 3 SCoPs detected ?
- This increases the possibility that Polly isn't handling the debug
info properly
- For opt kernel_gemm-after.ll $ANY_FLAG -o output.ll
- Cannot invoke an intrinsic other than donothing, patchpoint,
statepoint, coro_resume or coro_destroy
- store void (metadata, i64, metadata, metadata)* @llvm.dbg.value,
void (metadata, i64, metadata, metadata)** %polly_launch_0_param_7
- Invalid user of intrinsic instruction!
- store void (metadata, i64, metadata, metadata)* @llvm.dbg.value,
void (metadata, i64, metadata, metadata)** %polly_launch_0_param_7
- ./llvm_build/bin/opt: kernel_gemm-after.ll: error: input module is
broken!
- and output.ll isn't produced.
-Sanjay
Only target=gpu giving me error, but verufyModule is only in the path of
target=gpu.
On Sun, Mar 12, 2017 at 2:10 PM Tobias Grosser <tobias at grosser.es> wrote:
> On Sat, Mar 11, 2017, at 07:34 PM, David Blaikie via llvm-dev wrote:
> > On Sat, Mar 11, 2017 at 3:10 AM SANJAY SRIVALLABH SINGAPURAM via llvm-dev
> > <
> > llvm-dev at lists.llvm.org> wrote:
> >
> > > Hello,
> > >
> > > One of my Julia programs failed to execute with the following error,
> > > DICompileUnit not listed in llvm.dbg.cu
> > > !11 = distinct !DICompileUnit(language: DW_LANG_C89, file: !3,
> producer:
> > > "julia", isOptimized: true, runtimeVersion: 0,emissionKind: FullDebug,
> > > enums: !12)
> > >
> > > This was generated by verifyModule(*GPUModule,&(llvm::errs())From
> whithin
> > > PPCGCodeGeneration.cpp in Polly.
> > >
> > > From <llvm_src>/test/Verifier/dbg-orphaned-compileunit.ll, I understand
> > > that the debug info, of a compile unit, represented by !11 is missing
> from
> > > llvm.dbg.cu.
> > >
> > > What does this mean ? What could have caused this problem and how can I
> > > fix it ?
> > >
> >
> > At the LLVM level, it means that the CU debug info (DICompileUnit) wasn't
> > listed in the list of all compile units (!llvm.dbg.cu global named
> > metadata
> > node) when it should be. Whatever produced the IR you are using likely
> > has
> > a bug and should be fixed to ensure the DICompileUnits created are
> > included
> > in the !llvm.dbg.cu global named metadata node (check Clang's behavior
> > for
> > comparison - usually a good reference point)
> >
> > This invariant was added a while ago (in LLVM time - I think it was in
> > the
> > last year or maybe two) by Adrian.
>
> Right. It seems as if Julia is emitting invalid debug symbols. If you
> want to point them to this issue, you can probably call
> "verifyModule(*GPUModule))" after their initial IR is generated and
> already see the issue. If this is not the case, Polly might make a
> mistake when extracting the GPU module and might miss to transfer all
> debug information. Can you send me the output of the flag
> "-polly-dump-before"?
> Can you pass the dumped IR through 'opt' without seeing an error? In
> this case, the
> IR that enters Polly is still correct, but Polly might mis-transform it.
>
>
> An alternative fix would be to extract the debug-info stripping
> functionality in lib/Transforms/IPO/StripSymbols.cpp into its own
> function and call this on our Kernel-IR. It is unlikely that we want to
> debug GPU kernels, so we can just remove debug information for now.
>
> Best,
> Tobias
>
> >
> > - Dave
> >
> >
> > >
> > > Thank You,
> > > Sanjay
> > > _______________________________________________
> > > LLVM Developers mailing list
> > > llvm-dev at lists.llvm.org
> > > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> > >
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org
> > http://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/20170313/fe8954bd/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kernel_gemm-before.ll
Type: application/octet-stream
Size: 12296 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170313/fe8954bd/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kernel_gemm-after.ll
Type: application/octet-stream
Size: 31051 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170313/fe8954bd/attachment-0003.obj>
More information about the llvm-dev
mailing list