similar to: [LLVMdev] [PATCH] Improvements to BitCodeFormat.html

The enclosed patch adds documentation for the PARAMATTR_BLOCK, TYPE_BLOCK, and TYPE_SYMTAB_BLOCK records in the LLVM IR bitcode format. I have started documenting CONSTANTS_BLOCK and FUNCTION_BLOCK and will send patches when they are complete. -Peter- -------------- next part -------------- An HTML attachment was scrubbed... URL:

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:

At Thu, 15 Jul 2010 08:17:37 -0700, Peter Housel wrote: > The LLVM libraries provide the llvm::Intrinsic::getDeclaration() > function, which can provide a standard external declaration for any > of the (currently) 762 defined LLVM intrinsics, both for ordinary > intrinsics and for overrideable intrinsics with supplied parameter > types. Clients that do not link with the LLVM

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 issues (e.g. new

I think it just changed formats which prompted a change in ID -- the code now uses TYPE_BLOCK_ID_NEW (= 17). I haven’t looked deeply to see how different it is. Ismail > On Oct 13, 2016, 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: >>

Is there any good reason for using DW_FORM_data1 for the DW_AT_language attribute of DW_TAG_compile_unit? This prevents using language codes in the DW_LANG_lo_user=0x8000 to DW_LANG_hi_user=0xffff range. I think the obvious change to use DW_FORM_data2 in line 1897 of lib/CodeGen/AsmPrinter/DwarfDebug.cpp should fix it. Or, if there are binary compatibility issues, the abbrev form could be chosen

The enclosed patch adds a llvm.x86.int(i8) intrinsic expanding to the INT or INT3 instruction as appropriate. I haven't yet figured out the best way to select for the INTO instruction across basic blocks (hints would be welcome), but that can be added later with no changes in semantics. -Peter- On Aug 9, 2010, at 6:05 PM, Chris Lattner wrote: > After chatting on IRC, Peter wants a very

The LLVM libraries provide the llvm::Intrinsic::getDeclaration() function, which can provide a standard external declaration for any of the (currently) 762 defined LLVM intrinsics, both for ordinary intrinsics and for overrideable intrinsics with supplied parameter types. Clients that do not link with the LLVM libraries (such as the Open Dylan compiler, which has its own IR and its own bitcode

After chatting on IRC, Peter wants a very specific interrupt (int4 on x86). I suggested he add a new llvm.x86.int(i32) intrinsic, and use the existing branch on llvm.sadd.with.overflow intrinsic. The x86 backend can then turn jo+int4 into into when reasonable. -Chris On Aug 9, 2010, at 5:45 PM, Chris Lattner wrote: > > On Aug 9, 2010, at 10:44 AM, Peter S. Housel wrote: > >>

On Tue Nov 04 2014 at 12:43:05 PM Peter S. Housel <housel at acm.org> wrote: > On 11/04/2014 07:04 AM, Robinson, Paul wrote: > >> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Sean Silva > >> > >> You haven't established that you really need this. AFAIK Apple's linker > >> doesn't need this

On May 6, 2010, at 11:22 PM, Nathan Jeffords wrote: > Thanks! Funny, I was just preparing a patch to submit for my changes to MCSectionCOFF. My changes look to be fairly independent of yours, my change was to deal with COMDAT's. I had dealt with the characteristics flags in the object writer, but I like this. If you don't mind I would like to merge my changes into this patch and submit

Thanks! Funny, I was just preparing a patch to submit for my changes to MCSectionCOFF. My changes look to be fairly independent of yours, my change was to deal with COMDAT's. I had dealt with the characteristics flags in the object writer, but I like this. If you don't mind I would like to merge my changes into this patch and submit it. I was just pondering how to deal with the

On Fri, May 7, 2010 at 12:05 AM, Chris Lattner <clattner at apple.com> wrote: > > On May 6, 2010, at 11:22 PM, Nathan Jeffords wrote: > > Thanks! Funny, I was just preparing a patch to submit for my changes to > MCSectionCOFF. My changes look to be fairly independent of yours, my change > was to deal with COMDAT's. I had dealt with the characteristics flags in the >

On Sep 29, 2010, at 3:12 PM, Bill Wendling wrote: > Chris rewrote the original LLVM bytecode into 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:

On Tue, 10 Aug 2010 13:42:05 -0600 "Bueno, Denis" <denbuen at sandia.gov> wrote: > Hello, > http://www.opendylan.org/~housel/bcdump.pl > I'm trying to compile sqlite3 using llvm-gcc, then run it with lli. sqlite3 is part of LLVM testsuite, so it shouldn't crash ... > This builds with the exact same flags as above, but with -emit-llvm > added. It should

Hi, We would like to add a version number to the bitcode wrapper. This feature would allow easier identification of what compiler produced the bitcode so that known incompatibilities with LTO compilation could be detected. Roughly speaking, this version number would consist of the major, minor and optionally the patch version of the compiler used to produce the bitcode. The version information

On Aug 9, 2010, at 10:44 AM, Peter S. Housel wrote: > Several instruction set architectures include arithmetic operations that can trap on overflow, or support this feature with a separate trap-on-overflow-flag instruction (such as the x86 INTO instruction). > > > I am adding a back-end to the Open Dylan compiler to generate LLVM IR. The original back-end, which generates x86

> > 3.) Then I used clang-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:

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

> 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: