search for: dschuff

> 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> >> After look...

...imental 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 work today but...

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 to run with...

...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 actually ha...

> 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 Dec 9, 2015, at 4:...

> On Dec 9, 2015, at 4:13 PM, Quentin Colombet <qcolombet at apple.com> wrote: > > Hi, > > I would actually go the other direction, i.e., stick to physical registers but with an infinite number. > The rational is that after register allocation we broke all the nice properties of the pre-alloc virtual registers. For instance, the existing liveness algorithm cannot be used

...lcomm.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, sorry). That r...

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

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 you can leav...

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