An introduction and some questions

Gilles Duboscq gilles.m.duboscq at
Fri Nov 10 11:06:51 UTC 2017

Hi Jackson,

You'll need to sign the Oracle Contributor Agreement. The procedure is described there:

Please let us know when that's done.


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?
> 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> wrote:
>> Welcome Jackson!
>>> On 30 Oct 2017, at 18:27, Jackson Davis <jackson at> 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
>> 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:
>> 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

More information about the graal-dev mailing list