llvm dev - Dec 2012 - [LLVMdev] Proposal: Adding aligned instruction bundle support to MC

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 want to see the code and the diff against upstream,
our LLVM repo is in
https://gerrit.chromium.org/gerrit/gitweb?p=native_client%2Fpnacl-llvm.git;a=shortlog;h=refs%2Fheads%2Fmaster
All of our clang changes are upstream already.

-Derek

On Tue, Dec 4, 2012 at 5:23 PM, Greg Fitzgerald <garious at gmail.com>
wrote:
> 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 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 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 independently as feasible.
>>
>> One of the first things we'd like to start with is support for
aligned
>> instruction bundles in MC (assembler) level. This support exists in
>> gas since binutils version 2.23
>>
>>
(http://sourceware.org/binutils/docs/as/Bundle-directives.html#Bundle-directives).
>> Succinctly, the initial proposal is to add the following directives:
>>
>> .bundle_align_mode <num>
>> .bundle_lock
>> .bundle_unlock
>>
>> With the following semantics:
>>
>> When aligned instruction bundle mode ("bundling" in short) is
enabled
>> (.bundle_align_mode was encountered with an argument > 0, which is
the
>> power of 2 to which the bundle size is equal), single
>> instructions and groups of instructions between .bundle_lock and
>> .bundle_unlock directives cannot cross a bundle boundary.
>>
>> For example, consider the following:
>>
>> .bundle_align_mode 4
>> mov1
>> mov2
>> mov3
>>
>> Assuming that each of the mov instructions is 7 bytes long and mov1 is
>> aligned to a 16-byte boundary, two bytes of NOP padding will be
>> inserted between mov2 and mov3 to make sure that mov3 does not cross a
>> 16-byte bundle boundary.
>>
>> A slightly modified example:
>>
>> .bundle_align_mode 4
>> mov1
>> .bundle_lock
>> mov2
>> mov3
>> .bundle_unlock
>>
>> Here, since the bundle-locked sequence "mov2 mov3" cannot
cross a
>> bundle boundary, 9 bytes of NOP padding will be inserted between mov1
>> and mov2.
>>
>> For information on how this ability is used for software fault
>> isolation by Native Client, see the following resources:
>>
>> * http://src.chromium.org/viewvc/native_client/data/site/NaCl_SFI.pdf
[PDF
>> link]
>> *
>>
http://www.chromium.org/nativeclient/reference/arm-overview#TOC-The-Native-Client-Solution:-Bundles-
>> * Other papers listed at
>> http://www.chromium.org/nativeclient/reference/research-papers
>>
>> We want to start with this feature because it is self-contained in MC,
>> makes LLVM more compatible with gas, level and can be easily tested.
>> Future upstreaming efforts will be able to build upon this
>> functionality.
>>
>> Any comments, ideas and suggestions are welcome.
>>
>> Eli
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

> 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<https://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, 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 want to see the code and the diff against upstream,
> our LLVM repo is in
>
>
https://gerrit.chromium.org/gerrit/gitweb?p=native_client%2Fpnacl-llvm.git;a=shortlog;h=refs%2Fheads%2Fmaster
> All of our clang changes are upstream already.
>
> -Derek
>
> On Tue, Dec 4, 2012 at 5:23 PM, Greg Fitzgerald <garious at
gmail.com> wrote:
> > 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
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 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 independently as feasible.
> >>
> >> One of the first things we'd like to start with is support for
aligned
> >> instruction bundles in MC (assembler) level. This support exists
in
> >> gas since binutils version 2.23
> >>
> >> (
>
http://sourceware.org/binutils/docs/as/Bundle-directives.html#Bundle-directives
> ).
> >> Succinctly, the initial proposal is to add the following
directives:
> >>
> >> .bundle_align_mode <num>
> >> .bundle_lock
> >> .bundle_unlock
> >>
> >> With the following semantics:
> >>
> >> When aligned instruction bundle mode ("bundling" in
short) is enabled
> >> (.bundle_align_mode was encountered with an argument > 0, which
is the
> >> power of 2 to which the bundle size is equal), single
> >> instructions and groups of instructions between .bundle_lock and
> >> .bundle_unlock directives cannot cross a bundle boundary.
> >>
> >> For example, consider the following:
> >>
> >> .bundle_align_mode 4
> >> mov1
> >> mov2
> >> mov3
> >>
> >> Assuming that each of the mov instructions is 7 bytes long and
mov1 is
> >> aligned to a 16-byte boundary, two bytes of NOP padding will be
> >> inserted between mov2 and mov3 to make sure that mov3 does not
cross a
> >> 16-byte bundle boundary.
> >>
> >> A slightly modified example:
> >>
> >> .bundle_align_mode 4
> >> mov1
> >> .bundle_lock
> >> mov2
> >> mov3
> >> .bundle_unlock
> >>
> >> Here, since the bundle-locked sequence "mov2 mov3"
cannot cross a
> >> bundle boundary, 9 bytes of NOP padding will be inserted between
mov1
> >> and mov2.
> >>
> >> For information on how this ability is used for software fault
> >> isolation by Native Client, see the following resources:
> >>
> >> *
http://src.chromium.org/viewvc/native_client/data/site/NaCl_SFI.pdf[PDF
> >> link]
> >> *
> >>
>
http://www.chromium.org/nativeclient/reference/arm-overview#TOC-The-Native-Client-Solution:-Bundles-
> >> * Other papers listed at
> >> http://www.chromium.org/nativeclient/reference/research-papers
> >>
> >> We want to start with this feature because it is self-contained in
MC,
> >> makes LLVM more compatible with gas, level and can be easily
tested.
> >> Future upstreaming efforts will be able to build upon this
> >> functionality.
> >>
> >> Any comments, ideas and suggestions are welcome.
> >>
> >> Eli
> >> _______________________________________________
> >> LLVM Developers mailing list
> >> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> >
> >
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20121205/72214583/attachment.html>

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 great contribution.
>
Thanks for the feedback, and any help reviewing future patches will be
most appreciated :-)
It's also important to state that we plan to significantly clean-up
and refactor our code prior to upstreaming. Since in some areas the
changes are significant, this also means some refactoring of existing
LLVM code. My recent patches and commits in MC are the beginning of
this effort.

Eli