An introduction and some questions

[Jackson Davis]

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