search for: bitcodeformat

The enclosed patch contains a number of wording and clarity improvements to BitCodeFormat.html, and documents in detail the record types used within MODULE blocks. I plan to continue documenting the rest of the record types, but I wanted to submit patches in reasonably-sized pieces. -Peter S. Housel- housel at acm.org -------------- next part -------------- A non-text attachment was...

...es when they are complete. -Peter- -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100520/39b61edf/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: BitCodeFormat.diff Type: application/octet-stream Size: 12418 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100520/39b61edf/attachment.obj>

I wrote in a few weeks ago about writing an independent implementation of Bitcode and updating the docs to be more complete. Attached is a patch to docs/BitCodeFormat.html that adds a lot of information that was previously only available by reading the source code. It also corrects some errors. Josh -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20071008/3e04c452/att...

Hi folks, A while back I noticed some outdated information in docs/BitCodeFormat.rst about how parameter attributes were encoded — it describes an old encoding that was changed in 3.3 with the introduction of attribute groups. I opened a bug about this (https://llvm.org/bugs/show_bug.cgi?id=28941) and started trying to write a patch, but along the way ran into more and more iss...

...at 2:02 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > >> On Oct 13, 2016, at 10:24 AM, Ismail Badawi (ibadawi) via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> Hi folks, >> >> A while back I noticed some outdated information in docs/BitCodeFormat.rst about how parameter attributes were encoded — it describes an old encoding that was changed in 3.3 with the introduction of attribute groups. I opened a bug about this (https://llvm.org/bugs/show_bug.cgi?id=28941) and started trying to write a patch, but along the way ran into more and more iss...

...it's present bitcode form. The newer code is much smaller than the previous form. That would be my guess for why he chose to call it bitcode. Of course, he can say for himself. :-) The format is literally a bitstream, not a bytestream. See this document for more details: http://llvm.org/docs/BitCodeFormat.html -Chris

...r current meanings, and the new field BitcodeVersion is simply appended with the format described in the first paragraph. A second idea was to use the existing Version field in the bitcode wrapper format to store the bitcode version information. According to the documentation (http://llvm.org/docs/BitCodeFormat.html#bitcode-wrapper-format) this field is currently always set to 0. This would allow us to make use of what is (presumably) an unused field. As this is a feature that we feel would be beneficial to the community, we wanted to get feedback on the design for our upcoming patches. Any thoughts or o...

Am 30.09.2010 00:34, schrieb Chris Lattner: > > The format is literally a bitstream, not a bytestream. See this document for more details: > http://llvm.org/docs/BitCodeFormat.html Ah... something I always meant to ask: How does the LLVM infrastructure deal with the added overhead of packing/unpacking a bitstream? Ignore it since modern CPUs can deal with that? Some ingenious algorithm? Last time I heard about a bitstream format was with the i432, where hindsight lor...

> Anton, would it be possible to add information to the documentation > here: > http://llvm.org/docs/BitCodeFormat.html Sure! Any further comments? Many thanks, Anton. -------------- next part -------------- A non-text attachment was scrubbed... Name: half-doc.patch Type: application/octet-stream Size: 657 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120518/c416da...

...rate a .bc file - but now I'm not able to > use "llvm-readobj" anymore. Is there any tool available which can dump this > debug information too? > ​.bc is LLVM bitcode [1], not the usual object file. `llvm-readobj` should works only on the latter. ​[1] https://llvm.org/docs/BitCodeFormat.html -- Wei-Ren Chen (陳韋任) Homepage: https://people.cs.nctu.edu.tw/~chenwj -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180117/899fad67/attachment.html>

...e), cl::Hidden); Please remove this, the new writer should just always generate the relative encoding. Please feel free to land the patch with this change. Also, this is a significant enough thing that it would be good to add something to the bitcode docs (in the IR section, http://llvm.org/docs/BitCodeFormat.html#llvm-ir-encoding) that describes the old and new format. Thanks again for tackling this! -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121010/303678d1/attachment.html>

Anton, would it be possible to add information to the documentation here: http://llvm.org/docs/BitCodeFormat.html > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Villmow, Micah > Sent: Thursday, May 17, 2012 9:04 AM > To: Anton.Lokhmotov at arm.com; 'David Neto' > Cc: llvmdev at cs.uiuc.edu > Subject:...

Hello LLVM-World, I have a question about dumping debug information. 1.) I have compiled an object file with visual studio and debug information. Then I used "llvm-readobj -codeview" and dumped the debug information into a file. This is working great 2.) I used clang-cl for the same task and finally dumped it again with "llvm-readobj". Worked great too. 3.) Then I used

...ssion. - the LLVM code assumes that several VBR fields can be at most 32 bits (block ids, number of elements in an array, etc). These assumptions seem quite reasonable: can they be considered part of the format and added to the document? Cheers, Josh [0] http://llvm.org/releases/2.0/docs/BitCodeFormat.html

...ot able to >> use "llvm-readobj" anymore. Is there any tool available which can dump this >> debug information too? >> > > ​.bc is LLVM bitcode [1], not the usual object file. `llvm-readobj` should > works only on the latter. > > ​[1] https://llvm.org/docs/BitCodeFormat.html > > -- > Wei-Ren Chen (陳韋任) > Homepage: https://people.cs.nctu.edu.tw/~chenwj > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > ---------...

Thanks for the review Rafael! Chris, did you want to take a look at the patch too? Thanks, - Jan On Wed, Oct 10, 2012 at 12:39 PM, Rafael Espíndola < rafael.espindola at gmail.com> wrote: > On 10 October 2012 15:15, Jan Voung <jvoung at chromium.org> wrote: > > Yes, I had about 133K hits for INST_PHI with a negative value, out of > 136K > > hits of any

...r current meanings, and the new field BitcodeVersion is simply appended with the format described in the first paragraph. A second idea was to use the existing Version field in the bitcode wrapper format to store the bitcode version information. According to the documentation (http://llvm.org/docs/BitCodeFormat.html#bitcode-wrapper-format) this field is currently always set to 0. This would allow us to make use of what is (presumably) an unused field. As this is a feature that we feel would be beneficial to the community, we wanted to get feedback on the design for our upcoming patches. Any thoughts or o...

looks good here. > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Anton Lokhmotov > Sent: Thursday, May 17, 2012 4:51 AM > To: 'David Neto' > Cc: llvmdev at cs.uiuc.edu > Subject: Re: [LLVMdev] [PATCH] OpenCL half support > > Hi David, > > Many thanks for the comments! > >

...sidered part of the format and > added to the document? I don't see why not. The llvm bitcode documentation is specific to llvm anyway so the limits should be defined. Thanks for your interest, Joshua. Reid. > > Cheers, > Josh > > [0] http://llvm.org/releases/2.0/docs/BitCodeFormat.html > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

...-cl to generate a .bc file - but now I'm not able to use "llvm-readobj" anymore. Is there any tool available which can dump this debug information too? ​.bc is LLVM bitcode [1], not the usual object file. `llvm-readobj` should works only on the latter. ​[1] https://llvm.org/docs/BitCodeFormat.html -- Wei-Ren Chen (陳韋任) Homepage: https://people.cs.nctu.edu.tw/~chenwj _______________________________________________ LLVM Developers mailing list llvm-dev at lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev Als GmbH eingetragen im Handelsregister Bad Homburg v.d.H...