similar to: [LLVMdev] Proposal: Adding aligned instruction bundle support to MC

Hi Eli, > we are splitting the effort to manageable chunks that can > be committed, tested and reviewed separately as > independently as feasible I'd be interested in experimenting with this stuff sooner than later. Could you dump all the patches in a publicly accessible repo? How about Github? Thanks, Greg On Tue, Dec 4, 2012 at 3:53 PM, Eli Bendersky <eliben at

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

Hi Eli, How will these bundles interact with ARM codegen? The constant island pass in particular. -Jim On Dec 4, 2012, at 3:53 PM, Eli Bendersky <eliben at google.com> wrote: > Hello, > > We (the Portable Native Client team) would like to start upstreaming > our LLVM modifications which contain support for Software Fault > Isolation (SFI) as required for sandboxing

> But if you just want to see the code and the diff against upstream... If others are interested as well, here's all your changes via Github's "compare" feature:

On Thu, Dec 6, 2012 at 11:59 AM, Greg Fitzgerald <garious at gmail.com> wrote: > Maybe I'm jumping the gun, but some initial thoughts after browsing the MC > layer changes: > Greg, it's great to have early comments on this. > * .bundle_align_start -> .bundle_align_mode N ? > * .bundle_align_end -> .bundle_align_mode 0 ? The initial proposal does not cover

Maybe I'm jumping the gun, but some initial thoughts after browsing the MC layer changes: * .bundle_align_start -> .bundle_align_mode N ? * .bundle_align_end -> .bundle_align_mode 0 ? * Add unit test showing .bundle_lock/unlock can be nested. I like the way you modified the existing ARM tests to show how the existing instructions are predicated. Overall, I think the concept of

On Wed, Dec 5, 2012 at 6:01 PM, Greg Fitzgerald <garious at gmail.com> wrote: >> But if you just want to see the code and the diff against upstream... > > If others are interested as well, here's all your changes via Github's > "compare" feature: > > https://github.com/garious/llvm/compare/master...chromium > > Fascinating stuff guys. What a

>>> groups of instructions between .bundle_lock and >>> .bundle_unlock directives cannot cross a bundle boundary >> >> Can this be relaxed to: A data instruction cannot fall on a bundle >> boundary. ? > > I'm not sure what you mean, can you elaborate? Nevermind, what I suggested was not strict enough. I see now that the purpose of unlock/lock is to

This is parallel to the pre-SM50 change which does this. Adjusts the shuffles / quadops to make the values correct relative to lane 0, and then splat the results to all lanes for the final move into the target register. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- Entirely untested beyond compilation. Should check bin/tex-miplevel-selection textureGrad Cube

Hello, Background: We (the Portable Native Client team) would like to continue upstreaming our LLVM modifications which contain support for Software Fault Isolation (SFI) as required for sandboxing programs to run under Native Client. Since the "total patch size" is quite big, we are splitting the effort to manageable chunks that can be committed, tested and reviewed separately as

On Tue, Dec 19, 2017 at 11:41 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote: > This is parallel to the pre-SM50 change which does this. Adjusts the > shuffles / quadops to make the values correct relative to lane 0, and > then splat the results to all lanes for the final move into the target > register. > > Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> >

Am 19.06.2013 18:01, schrieb JF Bastien: > > From the provided documentation I understood that in memory data > structures of a PNaCl program are incompatible to the host program > because ABIs are different (e.g. PNaCl pointers are always 32-bit > even when running on x86_64 platform). > So PNaCl program can't access any data structures of the host >

> From the provided documentation I understood that in memory data > structures of a PNaCl program are incompatible to the host program because > ABIs are different (e.g. PNaCl pointers are always 32-bit even when running > on x86_64 platform). > So PNaCl program can't access any data structures of the host program > directly. The only communication way is by using syscalls,

All, We have our first CL ready and waiting, but haven't heard from the community. Are there issues or suggestions we should understand a priori? Cheers, David On Tue, Jan 15, 2013 at 3:59 PM, David Sehr <sehr at google.com> wrote: > Hello, > > Background: > We (the Portable Native Client team) would like to continue upstreaming > our LLVM modifications which

Marcus Zetterquist <marcus.zetterquist at gmail.com> writes: > Today we use Lua to let 3rd party developers add driver-like modules > to our application. > > The advantages to using Lua compared to DLL:s etc. are that: > > 1) the same driver binary can be used on all OS:es and processor > architectures etc. [snip] > I'm looking into using LLVM and the

Hi Eli, Recently, I proposed some changes to LLVM to do more lowering of illegal types (like i128 or i17) and other things within the LLVM IR layer, and the proposal was roundly rejected by the LLVM community: http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-April/061567.html PNaCl is essentially doing what my proposal described. How do you expect to reconcile the community's desire to avoid

Hi all, BitstreamReader is the only in-tree client of the DataStreamer and MemoryObject interfaces. In practice when using user-facing LLVM tools, the bitcode will normally either be in memory or in a file, so the best way to access it is through memory, either directly or memory mapped. As part of some refactorings I am making to BitstreamReader, I would like to simplify it by changing it to

And on a separate thread [0] Derek indicated he'd be fine with removing it. I'll leave this thread open until end of Monday to receive any other opinions, then proceed to remove it. Peter [0] http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20161024/400754.html On Fri, Oct 28, 2016 at 10:08 AM, Peter Collingbourne <peter at pcc.me.uk> wrote: > Hi all, > >

Hello, Following an earlier email ( http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-June/063010.html), we've published an initial version of the PNaCl bitcode reference manual online - http://www.chromium.org/nativeclient/pnacl/bitcode-abi. The PNaCl bitcode is a restricted subset of LLVM IR. The reference manual is quite terse, so for the bigger picture I'll repost links to the design

Awesome! Thanks, Rafael On 28 October 2016 at 13:14, Peter Collingbourne <peter at pcc.me.uk> wrote: > And on a separate thread [0] Derek indicated he'd be fine with removing it. > I'll leave this thread open until end of Monday to receive any other > opinions, then proceed to remove it. > > Peter > > [0] >