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

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

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 Native Client
is well-documented and easy to follow.  Has anyone done work to show that
assembly in this form can be disassembled to a memory-safe assembly
language like TAL?

> 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.  ?


Thanks,
Greg


On Wed, Dec 5, 2012 at 7:22 PM, Eli Bendersky <eliben at google.com>
wrote:
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20121206/b99ad357/attachment.html>

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 .bundle_align{start|end} on
purpose, to keep things simple. We do plan to add them, eventually,
probably as attributes on .bundle_lock.
> * Add unit test showing .bundle_lock/unlock can be nested.
Yes.
>
> I like the way you modified the existing ARM tests to show how the existing
> instructions are predicated.
Thanks. When upstreaming, I should remember using the new FileCheck
feature I recently added (variable references on the same line that
define them) which should make matching BICs more elegant.
> Overall, I think the concept of Native Client
> is well-documented and easy to follow.  Has anyone done work to show that
> assembly in this form can be disassembled to a memory-safe assembly
language
> like TAL?
>
>
>> 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?

Eli