similar to: Target triple normalzation through the LLVM C API

Hello Paul, Thanks for the reply. Yes, I am only looking for dwarf support at the moment and planning to support both PLI/COBOL decimal types. Also thanks for the suggestion, you are right as it is going to be rare cases, so it will be better to implement a separate subclass to avoid memory overhead for others. >> (Somebody is actively working on scaled binary operations, although they

Hello, Thanks for prompt reply. Motivation, In case of debugging of bi-endian dwarf and value known at runtime some of the raw values needs to be byte swapped to change the endianity. We have a llvm based compiler which generates such dwarf, TAG_variable marked as big endian and debugging on little endian host using lldb. The listed operator on dwarf issues does that, one operator instead of

> Could you please describe what is the benefit of that? Currently there are two ways to provide DISPFlagDefinition, via bool and SPFlag, I would like to make it only via SPFlags, it will be NFC and it will make the changes in parser simpler for moving five flags from from DIFlags to DISPFlags. Currently parser checks the presence of SPFlags to see if the definition is present in bool or spflag

Hello all, There is one enhancement request open for dwarfv5, http://dwarfstd.org/ShowIssue.php?issue=191107.1 The request is for addition of dwarf expression operator to swap the top of the dwarf stack, the response seems positive but it may take some time till v6. I like to add that operator as vendor extension but I am not sure how to go about it for llvm/lldb. Currently I am using it as

Adding tags on subject line From: Chirag Patel Sent: 22 August 2018 11:20 To: llvm-dev at lists.llvm.org Subject: DIBuilder missing interface to generate DWARF info for packed_decimal basic type. Hello, I am working on a llvm based compiler frontend in which, I am using the packed_decimal type encoding. During using the llvm DIBuilder, I found out that the interface to create BasicType with

Yes, removing the support for isLocal, isDefinition fields completely from ll files, currently the LLParser still parses it. I want to remove it and update the all the ll files which still uses it. Also the metadata read will support old format, no changes in that. so if ll file has isLocal and isDefinition it will result in parser error. But the bitcode read will work as usual. - Chirag.

On 2016-01-30 07:39, Eric Christopher wrote: > On Fri, Jan 29, 2016 at 8:38 PM whitequark <whitequark at whitequark.org> > wrote: > >> On 2016-01-30 07:36, Eric Christopher wrote: >>> It's known to be failing right now because of recent changes, but >> I'm >>> curious why that bot has ocaml installed for the bindings? >> >> I would

On Fri, Jan 29, 2016 at 8:38 PM whitequark <whitequark at whitequark.org> wrote: > On 2016-01-30 07:36, Eric Christopher wrote: > > It's known to be failing right now because of recent changes, but I'm > > curious why that bot has ocaml installed for the bindings? > > I would guess because I've been asking for OCaml to be installed > for quite some time

On 2016-01-30 07:36, Eric Christopher wrote: > It's known to be failing right now because of recent changes, but I'm > curious why that bot has ocaml installed for the bindings? I would guess because I've been asking for OCaml to be installed for quite some time :) > > -eric > > On Fri, Jan 29, 2016 at 8:34 PM Dmitri Gribenko via llvm-dev > <llvm-dev at

Hi all, It looks like I ended up reviewing most C API patches over the last few years. There's currently no code owner listed for the C API. I'd like to take it so that contributors know to tag me as a reviewer. Any objections? -- whitequark

I need some sort of utility to calculate a checksum of an Ogg file. Two differently encoded Ogg:s should give different checksums, but the same file with different tags should give the same result. (The serial number doesn't work here, obviously. I need something that is changed if a bit of the file is lost.) -- Björn Lindström <bkhl@elektrubadur.se> http://bkhl.elektrubadur.se/

Ah, that's why Clang is obsessively pushing them into return by reference? On Thu, May 24, 2018 at 6:29 PM, whitequark <whitequark at whitequark.org> wrote: > On 2018-05-25 00:39, Alexandre Isoard via llvm-dev wrote: > >> Hello, >> >> I see here: https://llvm.org/docs/LangRef.html#ret-instruction >> >> That the return instruction must only return

Hi all, We quickly talked with whitequark on IRC about this. I think he makes a good candidate. I also wrote and reviewed a lot of code in there, so if that's needed I can be in there. In any case, I voutch for whitequark. Amaury Séchet 2018-04-12 0:54 GMT+02:00 whitequark via llvm-dev <llvm-dev at lists.llvm.org>: > Hi all, > > It looks like I ended up reviewing most C API

Is there some tool for UN*X that basically checks if a file is a valid, intact, OGG file. I have had some bit rot and need to know what works and what doesn't, without having to listen through it all. -- Björn Lindström <bkhl@privat.utfors.se> Home page: http://hem.fyristorg.com/bkhl/ Blog: http://bkhl.livejournal.com/ Elektrubadur demo: http://hem.fyristorg.com/bkhl/elektrubadur/ ---

On 2018-05-11 02:28, Andrew Kelley via llvm-dev wrote: > In the Zig frontend, we know at compile-time the entire call graph. > This means we know stack size for all functions and therefore the > upper bound stack usage. > > [snip] > 1. Is there a way to accomplish this with existing LLVM API? You should use the @llvm.stacksave and @llvm.stackrestore intrinsic. It is only legal

On 2018-05-25 00:39, Alexandre Isoard via llvm-dev wrote: > Hello, > > I see here: https://llvm.org/docs/LangRef.html#ret-instruction > > That the return instruction must only return values of first class > types, which would exclude struct and arrays. But some llvm > instrinsics do return struct, and it does not seems to be enforced on > any function. > > Is that

Hello, I see here: https://llvm.org/docs/LangRef.html#ret-instruction That the return instruction must only return values of first class types, which would exclude struct and arrays. But some llvm instrinsics do return struct, and it does not seems to be enforced on any function. Is that restriction lifted and the documentation not up to date? Can we return arrays? I see the same restriction

Hello folks. I'm very interested in improving LLVM's OCaml bindings. I have several nontrivial patches sitting on llvm-commits for several weeks, and so far there's been little interest in them. Could someone with a good understanding of OCaml please take a look at these? 1) http://llvm-reviews.chandlerc.com/D1925 Every other function in OCaml bindings accepts context

Hi Nikita, Glad to hear that Rust code can benefit a lot from this. I have put patches to enable merge-similar functions with thinLTO. https://reviews.llvm.org/D52896 etc. <https://reviews.llvm.org/D52896> This is more powerful than existing merge-functions pass and all we need to do is port these patches to trunk llvm. I'd be happy to help with this effort. -Aditya

In the Zig frontend, we know at compile-time the entire call graph. This means we know stack size for all functions and therefore the upper bound stack usage. Recursive calls can have a runtime-decided stack usage, and therefore I am adding a frontend feature that will heap-allocate memory to use for some function calls. The idea is that recursion adds cycles to the call graph, and we know at