llvm dev - Aug 2019 - [ORC] [mlir] Dump assembly from OrcJit

+ MLIR dev mailing list since that’s where the OrcJit I’m using is.

Thanks for all the details, Lang! What you described is exactly what I’m looking
for!

Please, MLIR dev, let me know if this debug feature and the solution that Lang
describes below is interesting for MLIR. I’ll dig more into the details then but
it doesn’t seem too complicated.

Thanks,
Diego

From: Lang Hames [mailto:lhames at gmail.com]
Sent: Friday, August 16, 2019 1:07 PM
To: Caballero, Diego <diego.caballero at intel.com>
Cc: llvm-dev at lists.llvm.org
Subject: Re: [llvm-dev] [ORC] Dump assembly from OrcJit

Hi Diego,

That is probably your best option for dumping textual assembly directly, but
unless you need local symbol names and enhanced disassembly notes there is a
better option: Dump object files from the JIT and disassemble them. Dumping
object files has two advantages over assembly: (1) it avoids redundant codegen,
so is much faster, and (2) the bits you're dumping are *exactly* the bits
flowing into the JIT linker: there is no chance of getting misleading assembly
due to a compiler misconfiguration or persistent state bug.

One way to dump object files, which works for both LLJIT and custom stacks, is
to attach a dummy ObjectCache (see
https://github.com/llvm/llvm-project/blob/master/llvm/examples/LLJITExamples/LLJITWithObjectCache/LLJITWithObjectCache.cpp)
and dump the ObjBuffers that are passed in to the cache to disk. You can just
return 'nullptr' from your dummy cache's getObject method, since you
are not really using it as a cache.

Alternatively, If you are writing a custom ORC stack there is a second option:
You can insert an ObjectTransformLayer between your IRCompileLayer and
ObjectLinkingLayer and use that to dump the buffers to disk.

I hope this helps!

-- Lang.

On Thu, Aug 15, 2019 at 3:44 PM Caballero, Diego via llvm-dev <llvm-dev at
lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:
Hi all,

Is there a way to dump the generated assembly from OrcJit? I found this thread
about MCJIT but nothing specific about OrcJit:
http://lists.llvm.org/pipermail/llvm-dev/2014-June/074145.html
I’m also aware of the alternative approach below, but I’m not sure if the output
will be the same as the assembly generated by OrcJit. Probably not.

    std::string outStr;
    {
      llvm::legacy::PassManager pm;
      llvm::raw_string_ostream stream(outStr);
      llvm::buffer_ostream pstream(stream);
      targetMachine->addPassesToEmitFile(pm, pstream, nullptr,
                                        
llvm::TargetMachine::CGFT_AssemblyFile);
      pm.run(*m);
    }
    llvm::errs() << "Assembly:\n" << outStr <<
"\n";

Thanks!
Diego

_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
https://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/20190816/13eb062a/attachment.html>

Would be great to have!
I was looking for how to do something like this just a few days ago.


On Fri, Aug 16, 2019, 5:44 PM Caballero, Diego <diego.caballero at
intel.com>
wrote:
> + MLIR dev mailing list since that’s where the OrcJit I’m using is.
>
>
>
> Thanks for all the details, Lang! What you described is exactly what I’m
> looking for!
>
>
>
> Please, MLIR dev, let me know if this debug feature and the solution that
> Lang describes below is interesting for MLIR. I’ll dig more into the
> details then but it doesn’t seem too complicated.
>
>
>
> Thanks,
>
> Diego
>
>
>
> *From:* Lang Hames [mailto:lhames at gmail.com]
> *Sent:* Friday, August 16, 2019 1:07 PM
> *To:* Caballero, Diego <diego.caballero at intel.com>
> *Cc:* llvm-dev at lists.llvm.org
> *Subject:* Re: [llvm-dev] [ORC] Dump assembly from OrcJit
>
>
>
> Hi Diego,
>
>
>
> That is probably your best option for dumping textual assembly directly,
> but unless you need local symbol names and enhanced disassembly notes there
> is a better option: Dump object files from the JIT and disassemble them.
> Dumping object files has two advantages over assembly: (1) it avoids
> redundant codegen, so is much faster, and (2) the bits you're dumping
are
> *exactly* the bits flowing into the JIT linker: there is no chance of
> getting misleading assembly due to a compiler misconfiguration or
> persistent state bug.
>
>
>
> One way to dump object files, which works for both LLJIT and custom
> stacks, is to attach a dummy ObjectCache (see
>
https://github.com/llvm/llvm-project/blob/master/llvm/examples/LLJITExamples/LLJITWithObjectCache/LLJITWithObjectCache.cpp)
> and dump the ObjBuffers that are passed in to the cache to disk. You can
> just return 'nullptr' from your dummy cache's getObject method,
since you
> are not really using it as a cache.
>
>
>
> Alternatively, If you are writing a custom ORC stack there is a second
> option: You can insert an ObjectTransformLayer between your IRCompileLayer
> and ObjectLinkingLayer and use that to dump the buffers to disk.
>
>
>
> I hope this helps!
>
>
>
> -- Lang.
>
>
>
> On Thu, Aug 15, 2019 at 3:44 PM Caballero, Diego via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
> Hi all,
>
>
>
> Is there a way to dump the generated assembly from OrcJit? I found this
> thread about MCJIT but nothing specific about OrcJit:
> http://lists.llvm.org/pipermail/llvm-dev/2014-June/074145.html
>
> I’m also aware of the alternative approach below, but I’m not sure if the
> output will be the same as the assembly generated by OrcJit. Probably not.
>
>
>
>     std::string outStr;
>
>     {
>
>       llvm::legacy::PassManager pm;
>
>       llvm::raw_string_ostream stream(outStr);
>
>       llvm::buffer_ostream pstream(stream);
>
>       targetMachine->addPassesToEmitFile(pm, pstream, nullptr,
>
>
> llvm::TargetMachine::CGFT_AssemblyFile);
>
>       pm.run(*m);
>
>     }
>
>     llvm::errs() << "Assembly:\n" << outStr <<
"\n";
>
>
>
> Thanks!
>
> Diego
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
> --
> You received this message because you are subscribed to the Google Groups
> "MLIR" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mlir+unsubscribe at tensorflow.org.
> To view this discussion on the web visit
>
https://groups.google.com/a/tensorflow.org/d/msgid/mlir/025727872606CE4AA31D9EF6945969BA3CB6E57D%40ORSMSX115.amr.corp.intel.com
>
<https://groups.google.com/a/tensorflow.org/d/msgid/mlir/025727872606CE4AA31D9EF6945969BA3CB6E57D%40ORSMSX115.amr.corp.intel.com?utm_medium=email&utm_source=footer>
> .
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190816/fe6b6baf/attachment.html>

Indeed, dumping the assembly would be a helpful option for mlir-*-runner.

On Sat, Aug 17, 2019 at 1:05 AM Nicolas Vasilache <
nicolas.vasilache at gmail.com> wrote:
> Would be great to have!
> I was looking for how to do something like this just a few days ago.
>
>
> On Fri, Aug 16, 2019, 5:44 PM Caballero, Diego <diego.caballero at
intel.com>
> wrote:
>
>> + MLIR dev mailing list since that’s where the OrcJit I’m using is.
>>
>>
>>
>> Thanks for all the details, Lang! What you described is exactly what
I’m
>> looking for!
>>
>>
>>
>> Please, MLIR dev, let me know if this debug feature and the solution
that
>> Lang describes below is interesting for MLIR. I’ll dig more into the
>> details then but it doesn’t seem too complicated.
>>
>>
>>
>> Thanks,
>>
>> Diego
>>
>>
>>
>> *From:* Lang Hames [mailto:lhames at gmail.com]
>> *Sent:* Friday, August 16, 2019 1:07 PM
>> *To:* Caballero, Diego <diego.caballero at intel.com>
>> *Cc:* llvm-dev at lists.llvm.org
>> *Subject:* Re: [llvm-dev] [ORC] Dump assembly from OrcJit
>>
>>
>>
>> Hi Diego,
>>
>>
>>
>> That is probably your best option for dumping textual assembly
directly,
>> but unless you need local symbol names and enhanced disassembly notes
there
>> is a better option: Dump object files from the JIT and disassemble
them.
>> Dumping object files has two advantages over assembly: (1) it avoids
>> redundant codegen, so is much faster, and (2) the bits you're
dumping are
>> *exactly* the bits flowing into the JIT linker: there is no chance of
>> getting misleading assembly due to a compiler misconfiguration or
>> persistent state bug.
>>
>>
>>
>> One way to dump object files, which works for both LLJIT and custom
>> stacks, is to attach a dummy ObjectCache (see
>>
https://github.com/llvm/llvm-project/blob/master/llvm/examples/LLJITExamples/LLJITWithObjectCache/LLJITWithObjectCache.cpp)
>> and dump the ObjBuffers that are passed in to the cache to disk. You
can
>> just return 'nullptr' from your dummy cache's getObject
method, since you
>> are not really using it as a cache.
>>
>>
>>
>> Alternatively, If you are writing a custom ORC stack there is a second
>> option: You can insert an ObjectTransformLayer between your
IRCompileLayer
>> and ObjectLinkingLayer and use that to dump the buffers to disk.
>>
>>
>>
>> I hope this helps!
>>
>>
>>
>> -- Lang.
>>
>>
>>
>> On Thu, Aug 15, 2019 at 3:44 PM Caballero, Diego via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>
>> Hi all,
>>
>>
>>
>> Is there a way to dump the generated assembly from OrcJit? I found this
>> thread about MCJIT but nothing specific about OrcJit:
>> http://lists.llvm.org/pipermail/llvm-dev/2014-June/074145.html
>>
>> I’m also aware of the alternative approach below, but I’m not sure if
the
>> output will be the same as the assembly generated by OrcJit. Probably
not.
>>
>>
>>
>>     std::string outStr;
>>
>>     {
>>
>>       llvm::legacy::PassManager pm;
>>
>>       llvm::raw_string_ostream stream(outStr);
>>
>>       llvm::buffer_ostream pstream(stream);
>>
>>       targetMachine->addPassesToEmitFile(pm, pstream, nullptr,
>>
>>
>> llvm::TargetMachine::CGFT_AssemblyFile);
>>
>>       pm.run(*m);
>>
>>     }
>>
>>     llvm::errs() << "Assembly:\n" << outStr
<< "\n";
>>
>>
>>
>> Thanks!
>>
>> Diego
>>
>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>> --
>> You received this message because you are subscribed to the Google
Groups
>> "MLIR" group.
>> To unsubscribe from this group and stop receiving emails from it, send
an
>> email to mlir+unsubscribe at tensorflow.org.
>> To view this discussion on the web visit
>>
https://groups.google.com/a/tensorflow.org/d/msgid/mlir/025727872606CE4AA31D9EF6945969BA3CB6E57D%40ORSMSX115.amr.corp.intel.com
>>
<https://groups.google.com/a/tensorflow.org/d/msgid/mlir/025727872606CE4AA31D9EF6945969BA3CB6E57D%40ORSMSX115.amr.corp.intel.com?utm_medium=email&utm_source=footer>
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "MLIR" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mlir+unsubscribe at tensorflow.org.
> To view this discussion on the web visit
>
https://groups.google.com/a/tensorflow.org/d/msgid/mlir/CAC42N1pgM8swQOw9JcaKKcOrFTU%2B7Ue3qJNH0sccU_E5k2QRjw%40mail.gmail.com
>
<https://groups.google.com/a/tensorflow.org/d/msgid/mlir/CAC42N1pgM8swQOw9JcaKKcOrFTU%2B7Ue3qJNH0sccU_E5k2QRjw%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>

-- 
-- Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190819/76811487/attachment.html>