search for: vtjnash

...terate that I am still seeking all opinions about the use of tokens and operand bundles or any other means of representing the fp constraints. I just want to make sure that we all have the same understanding of what the information I’m trying to represent in IR means. -Andy From: Jameson Nash <vtjnash at gmail.com> Sent: Thursday, November 14, 2019 8:00 PM To: Kaylor, Andrew <andrew.kaylor at intel.com> Cc: LLVM Developers Mailing List <llvm-dev at lists.llvm.org> Subject: Re: [llvm-dev] RFC: token arguments and operand bundles I understand that, but I think you missed my point....

...l constant values is that it provides no information when you’re reading the IR. For example: %sum = call double @llvm.experimental.constrained.fadd(double %x, double %y, i32 1, i32 2) What does that mean? You’d need to consult an external reference to have any idea. -Andy From: Jameson Nash <vtjnash at gmail.com> Sent: Thursday, November 14, 2019 12:27 PM To: Kaylor, Andrew <andrew.kaylor at intel.com> Cc: LLVM Developers Mailing List <llvm-dev at lists.llvm.org> Subject: Re: [llvm-dev] RFC: token arguments and operand bundles From a front-end perspective, I think it'd be p...

...aLang), I'm additionally interested in whether some bits of this make sense to end up in libLLVM itself. Probably especially the collection code pieces. For context, I've previously written some code to pretty-print the line-table information as code comments (sample https://gist.github.com/vtjnash/2f2b642663655d5fc63ec7321c5bd0bd, implementation https://github.com/JuliaLang/julia/blob/master/src/disasm.cpp#L167), and it's been on my mind ever since to figure out if some portion of that made sense to upstream, if any. And also to figure out how to parse and show the variable info along it...

...uld perform the load every time; ideally memory accesses would be able to be cached. This is why I’ve been leaning towards disabling the part of instcombine that combines memory accesses instead of using volatile — there should be better performance. On Apr 17, 2019, 9:54 AM -0700, Jameson Nash <vtjnash at gmail.com>, wrote: > The lang ref promises that, "the backend should never ... merge target-legal volatile load/store instructions". Which I've usually assumed meant that it was promised? Just curious if you thought this left some wiggle room for some optimizations, since my...

Historically? I implemented support for exceptions back in LLVM 3.3, before LLVM had an implementation of a Windows unwinder. Currently? As recent as LLVM 4.0, I don't think the JIT was fully capable of handling COFF files, and LLVM wouldn't emit the correct sections (with the COFF-formatted unwind tables) when used in ELF mode. The prolog is known to be standard since Julia disables FPO

...ld get rid of relocation problems. But it might then be tricky to build the unwind information. (Perhaps this wouldn't be feasible in a static environment, but it's possible in a JIT environment, since this is indeed how it's done in JuliaLang). > > From: Jameson Nash <vtjnash at gmail.com> > To: Hayden Livingston <halivingston at gmail.com>, > bjoern.gaier at horiba.com > Cc: LLVM Developers Mailing List <llvm-dev at lists.llvm.org>, Stefan > Gränitz <stefan.graenitz at gmail.com> > Date: 16.10.2017 23:04 > Sub...

I've always just hacked support for this in to the various JITs (for JuliaLang, in our debuginfo.cpp file), by setting the no-frame-pointer-optim flag in the IR, then creating and populating a dummy unwind description object in the .text section, and registering that dynamically. Some day I hope to actually just register the .pdata/.xdata sections with the unwinder. PDBs are a bit different

> On Apr 17, 2019, at 5:02 AM, Arsenault, Matthew via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > This won’t happen with volatile load/store This is mostly true today, but AFAICT the LLVM memory model doesn’t actually offer this guarantee. It merely says that LLVM treats volatile like C / C++ treats volatile… which isn’t much of a guarantee because C / C++ volatile doesn’t

Hi all, Need your help. I added some debug information to my code according to Kaleidoscope-9 sample and got stuck with a GDB error: (gdb) info functions > invalid dwarf2 offset 1849950870 > My module is a DLL built with llc+ld toolchain. Target triple: 'i686-w64-mingw32'. Looking this offset (1849950870 == 0x6e440296) in dwarfdump output of the dll gave the following:

For a datapoint, Julia uses the following function description to implement approximately the capability of those functions. We then also verify that there's no direct inttoptr/ptrtoint into our gc-tracked AddressSpace with a custom verifier pass (among other sanity checks). I can provide additional details and pointers to our gc-root tracking algorithm implementation if desired (I also plan

I don't think it's especially hard, but just not specifically unimplemented because nobody's had a strong need for it. There's probably some combinations of code models and machines that does happen to work (e.g. emutls+linux+large-code+large-data+no-PIC). Julia has some support for thread locals, but as a JIT in control of the language we currently try to generate better code than

...vable access to the code will be through its entry point. P.S. - I'm also assuming that the ELF object container format does not drive the code-generation triple, i.e. we generate Windows ABI Compatible code even when using the RuntimeDyIDELF. On Tue, Oct 3, 2017 at 10:17 PM, Jameson Nash <vtjnash at gmail.com> wrote: > In partial answer to your question, I can state that JuliaLang has been > successfully registering and handling exceptions in JIT code since LLVM 3.3, > when I implemented support (with varying levels of hackiness over time to > support all of the JIT and other...

Hi llvm-dev, I've uploaded a prototype patch at https://reviews.llvm.org/D70720 which adds a new feature to llvm-objdump: displaying the location (in registers/memory/etc) of source-level variables alongside the disassembly display. I've put a demo of the output at https://reviews.llvm.org/M2. I have two use-cases in mind for this: * Users reading the disassembly of compiled code. It

Hello everyone, I've just uploaded a patch (https://reviews.llvm.org/D70261) to introduce a could of new token types to be used with constrained floating point intrinsics and, optionally, vector predicated intrinsics. These intrinsics may not be of interest to many of you, but I have a more general question. I would like some general feedback on the way I am proposing to use token arguments

I'm catching up on this. Does this mean LLVM x64 JITTed code is not exception friendly or you can't catch exceptions inside LLVM JITTed code. The first one seems to indicate that the code is not ABI friendly or that not enough information is present to notify Windows of unwind tables. I'll ask the question another way: Does LLVM emit enough information so that RtlAddFunctionTable can