search for: schuff

...liveness algorithm cannot be used on those virtual registers. On the other hand, all the infrastructure we have in place for physical registers would be suited. (modulo supporting a dynamic number of physical registers) > > Cheers, > Q. > >> On Dec 9, 2015, at 4:04 PM, Derek Schuff via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> >> >> On Wed, Dec 9, 2015 at 3:02 PM Hal Finkel <hfinkel at anl.gov <mailto:hfinkel at anl.gov>> wrote: >> ----- Original Message ----- >> > F...

On Wed, Dec 9, 2015 at 3:02 PM Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- > > From: "Derek Schuff via llvm-dev" <llvm-dev at lists.llvm.org> > > To: llvm-dev at lists.llvm.org > > Sent: Wednesday, December 9, 2015 4:31:31 PM > > Subject: [llvm-dev] Allowing virtual registers after register allocation > > > > > > Hi all, > > Virtual ISAs such...

Hi Pavel, We (the Native Client team) are also interested in helping you get these reviewed and in, especially the x86 backend stuff. Native Client's x86-64 ABI is similar to x32 so we could probably share a good portion of the code if it's structured the right way. -Derek On 1404316081542, Dmitri Gribenko <gribozavr at gmail.com> wrote: > On Wed, Jul 2, 2014 at 3:59 PM, Pavel

> On Dec 10, 2015, at 10:49 AM, Derek Schuff <dschuff at google.com> wrote: > > > > On Thu, Dec 10, 2015 at 10:13 AM Quentin Colombet <qcolombet at apple.com <mailto:qcolombet at apple.com>> wrote: > > I am tempted to think no, we don’t, but I don’t know the use cases. > What post-RA passes with want...

> On Dec 10, 2015, at 9:39 AM, Hal Finkel <hfinkel at anl.gov> wrote: > > > > ----- Original Message ----- >> From: "Quentin Colombet" <qcolombet at apple.com> >> To: "Derek Schuff" <dschuff at google.com> >> Cc: "Hal Finkel" <hfinkel at anl.gov>, llvm-dev at lists.llvm.org >> Sent: Wednesday, December 9, 2015 6:14:33 PM >> Subject: Re: [llvm-dev] Allowing virtual registers after register allocation >> >> >> On...

Are you using static linking, -DBUILD_SHARED_LIBS, or -DLLVM_LINK_LLVM_DYLIB? On Tue, Jan 8, 2019 at 7:21 AM David Greene via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Rui Ueyama <ruiu at google.com> writes: > > > I cannot reproduce this error, but this could be real. > > > > David, is this reproducible every time or is this flaky? > > It's

...or my experimental convenience (unless you think it's actually better that way). Thanks for your help, -Derek On Wed, Jan 13, 2016 at 3:40 PM Quentin Colombet <qcolombet at apple.com> wrote: > Hi Derek, > > Thanks for tackling this. > > On Jan 13, 2016, at 3:32 PM, Derek Schuff <dschuff at google.com> wrote: > > We had some additional discussion on this. There is a lot of concern > generally about post-RA passes which do not expect to have to handle > virtual registers; specifically if they unexpectedly start seeing virtual > registers, or if they wor...

Hello all, The rich history of binary distribution formats based on LLVM [0][1][2][3][4] has proven LLVM's viability as a launchpad for stable platforms. However, issues with compilation time and compiler size have suggested that the translator must do too much, i.e. LLVM IR isn't a low-level enough virtual machine. So we introduce DAGIR ("dagger"), a new portable close to the

> On Jan 22, 2016, at 1:23 PM, Matthias Braun <mbraun at apple.com> wrote: > >> >> On Jan 22, 2016, at 12:29 PM, Derek Schuff <dschuff at google.com <mailto:dschuff at google.com>> wrote: >> >> Here are 2 patches, which are independent of each other. >> >> The first splits PrologEpilogInserter into 2 parts : http://reviews.llvm.org/D16481 <http://reviews.llvm.org/D16481> >&gt...

Hi all, Virtual ISAs such as WebAssembly and NVPTX use infinite virtual register sets instead of traditional phsyical registers. PrologEpilogInserter is run after register allocation and asserts that all virtuals have been allocated but doesn't otherwise depend on this if scavenging is not needed. We'd like to use the target-independent PEI code for WebAssembly, so we're proposing a

...yPhysReg() just handles vregs) and is otherwise agnostic. MachineBlockPlacement doesn't do anything at all to any MachineInstrs itself, but just relies on TargetInstrInfo methods to update the branches. I'll post again later with the prototype code. On Thu, Dec 10, 2015 at 3:52 PM Derek Schuff <dschuff at google.com> wrote: > On Thu, Dec 10, 2015 at 2:46 PM Matthias Braun via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> To say this first: This whole discussion about using virtregs until emit >> or having growable physregs is hard to argue without...

Hi Fangrui, As you noted we are working on helping our NaCl users transition to WebAssembly and new web APIs that cover the functionality offered by NaCl. In terms of actually turning down the platform features, we recently announced a timeline at https://blog.chromium.org/2020/01/moving-forward-from-chrome-apps.html. In terms of LLM, I would prefer to keep the support we have in the tree until

...9;t think keeping the code in LLVM is actually useful for anyone at this point. Right, I think this is the key issue. If the community cannot use the code that is in tree, there isn’t a strong reason for the community to maintain it. -Chris > > > On Mon, Apr 20, 2020 at 4:22 PM Derek Schuff via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > Hi Fangrui, > As you noted we are working on helping our NaCl users transition to WebAssembly and new web APIs that cover the functionality offered by NaCl. In terms of actually turning down the...

.../mymail.qualcomm.com/owa/redir.aspx?C=yu3Jo4nVdU6kh1OLiSe-04bnBhWtps8IxTOCi0lWLdEE4UxDImiKxfAW68FhXG16blXtZLHc6Xs.&URL=https%3a%2f%2fgithub.com%2fgarious%2fllvm%2fcompare%2fmaster...chromium> Fascinating stuff guys. What a great contribution. -Greg On Tue, Dec 4, 2012 at 9:03 PM, Derek Schuff <dschuff at google.com> wrote: > Hi Greg, > Our repos are public already, hosted on the Chromium infrastructure. > Our builds are based out of the Native Client repository. The nacl git > mirror is at http://git.chromium.org/native_client/src/native_client.git > (no gitweb, so...

I had considered a libraries/Backends:Other as well that would be separate from libraries/Other On Fri, Nov 9, 2018 at 11:20 AM Derek Schuff <dschuff at google.com> wrote: > I wonder if backends are a special case to the heuristic of "let's not > make a bug component for code components that are too small". LLVM is > factored to cleanly separate backend code, to the point where it's the one > thing...

Hi Greg, Our repos are public already, hosted on the Chromium infrastructure. Our builds are based out of the Native Client repository. The nacl git mirror is at http://git.chromium.org/native_client/src/native_client.git (no gitweb, sorry). That repo has pointers to a bunch of other repos which make pnacl (LLVM, clang, binutils, and a few others. see the file pnacl/DEPS for more). But if you just

Using LLVM v5, my Cone compiler (https://github.com/jondgoodwin/cone) automatically directly generated all functions as named and exported for both wasm text and binary files (not using clang/lld etc, but using the API). Upgrading to LLVM v7, generated wasm object files now fail, exhibiting markedly different behavior, behavior that varies between the text and binary files. For example, the

To say this first: This whole discussion about using virtregs until emit or having growable physregs is hard to argue without actually having experience trying to go either way. Problems when using virtregs throughout the backend until emit time: - The MC layer is using MCPhysReg (which is an uint16_t) and would need retrofitting to support virtregs - VirtRegs are assumed to have a definition,

Hi Zach, Thanks for elaborating. I like your proposal. I agree it still groups per area of expertise. And it makes the set of components we have easier to manage. Before making changes though I hope to hear opinions from others on this. What do others think? Thanks, Kristof On 9 Nov 2018, at 18:05, Zachary Turner <zturner at google.com<mailto:zturner at google.com>> wrote: To