An introduction and some questions

[Jackson Davis]

Hi Gilles,

OCA is signed: http://www.oracle.com/technetwork/community/oca-486395.html#d

Thanks
-Jackson


On Fri, Nov 10, 2017 at 3:06 AM, Gilles Duboscq <gilles.m.duboscq at oracle.com
> wrote:

> Hi Jackson,
>
> You'll need to sign the Oracle Contributor Agreement. The procedure is
> described there:
> http://www.oracle.com/technetwork/community/oca-486395.html
>
> Please let us know when that's done.
>
>  Gilles
>
> On 10/11/17 11:57, Jackson Davis wrote:
> > I've cleaned this up and turned this into a PR, was wondering if someone
> > could take a look?
> >
> > https://github.com/graalvm/graal/pull/263
> >
> > This only considers add/sub for constants > 1, for which using lea is
> > always at least as short, if not shorter.
> >
> > Thanks,
> > -Jackson
> >
> >
> > On Mon, Oct 30, 2017 at 12:53 PM, Doug Simon <doug.simon at oracle.com>
> wrote:
> >
> >> Welcome Jackson!
> >>
> >>> On 30 Oct 2017, at 18:27, Jackson Davis <jackson at jcdav.is> wrote:
> >>>
> >>> Hello,
> >>>
> >>> I've been trying to finally introduce myself to graal over the last few
> >>> days, with a hope I can maybe sneak in a few changes when I have time -
> >> its
> >>> an interesting project :)
> >>>
> >>> On the non-technical side: Whats with the [GR-XXXX] in commit messages,
> >> is
> >>> this a private issue tracker? I don't see anything on the graal project
> >> on
> >>> openjdk jira, or anywhere else for that matter.
> >>
> >> These are indeed related to an internal jira instance Graal shares with
> a
> >> number of other projects at Oracle Labs, some of which are not open
> source.
> >>
> >> We also respond to issues and pull requests at
> https://github.com/graalvm/
> >> graal.
> >>
> >>> On the technical side: I've been looking into optimizing the code
> >>> generation on x86 for add/sub/shl. Currently, if reg1 and reg2 are
> >>> different, reg2 = add reg1, C generates
> >>> mov %reg1, %reg2
> >>> add C, %reg2
> >>>
> >>> This can be folded into a single lea C(%reg1), %reg2 (if there is no
> >>> resulting operation dependent on flags being set). We can do the same
> for
> >>> sub, and for shl if C=1/2/3. I have a very basic attempt of this
> >>> working-ish here:
> >>> https://github.com/jcdavis/graal/commit/6d27c585726b64259635f36542263c
> >> a0cde3dcf1
> >>> . This currently always uses leaq, which is at best 1 byte longer than
> it
> >>> needs to be for 32 bit operands (since the REX prefix isn't necessary),
> >> and
> >>> at worst possibly wrong because over/underflow will set the high order
> 32
> >>> bits (which might be ok? But unsure). It also misses add/sub by 1
> (since
> >>> those are lowered to MOp, not ConstOp), and also doesn't consider
> %reg3 =
> >>> %reg1 + %reg2 (which can also be represented as an lea)
> >>>
> >>> Where I am a little lost is how to clean this up properly. I was
> >> thinking a
> >>> new emit function that also takes a source register x could be added,
> >> which
> >>> be default would still call the same move + emit, and then, individual
> >>> opcodes could override that behavior as necessary?
> >>
> >> I would suggest implementing and testing your suggestion then
> submitting a
> >> PR on github to allow someone more familiar than I am with this part of
> the
> >> compiler to offer feedback.
> >>
> >> -Doug
>