1223355 - Common out x86/x64 constant pool code

Status: RESOLVED FIXED

(Core :: JavaScript Engine: JIT, defect)

Description

[Benjamin Bouvier [:bbouvier] (inactive)]

The code for generating constant pools on x86 and x64 should be shared.

The only issue is the following:
- MacroAssemblerX86 and MacroAssemblerX64 both inherit from MacroAssemblerX86Shared.
- Each masm uses different label types for chaining the uses of a constant (NonAssertingLabel on x64, AbsoluteLabel on x86).

Templates to the rescue!

Comment 1

[Benjamin Bouvier [:bbouvier] (inactive)]

Attachment: patch

Comment 2

[Dan Gohman [:sunfish]]

Comment on attachment 8685425 [details] [diff] [review]
patch

Review of attachment 8685425 [details] [diff] [review]:
-----------------------------------------------------------------

Another way to do the refactoring would be to make MacroAssemblerX86Shared a template with PlatformSpecificLabel its template parameter. That would allow things like Double, Float, etc. to use PlatformSpecificLabel without having to be templates themselves (and would avoid the "<>" in a bunch of places).

Comment 3

[Dan Gohman [:sunfish]]

Comment on attachment 8685425 [details] [diff] [review]
patch

Review of attachment 8685425 [details] [diff] [review]:
-----------------------------------------------------------------

bbouvier pointed out on irc that the refactoring I suggested here would require definitions of MacroAssemblyerX86Shared member functions to have templated declarations, making them more verbose.

Comment 4

[Benjamin Bouvier [:bbouvier] (inactive)]

I've tried the approach in comment 2. It seems that the compilers (tested with g++4.8 and clang++3.4) won't allow to have specialized templated versions of a function with a non-specialized enclosing template.

e.g. for template<class T> MacroAssemblerX86Shared::loadAlignedVector, you can't have
class <typename L>
class <>
MacroAssemblerX86Shared<L>::loadAlignedVector<int32_t>(...) { ... }

So we would need to explicitly instantiate (that is, copy) the methods for L in {NonAssertingLabel, AbsoluteLabel}, which sounds even uglier, in which case, the initial approach looks better.

I will let this patch sit around a few days, to see if anybody has a better idea.

Comment 5

[Benjamin Bouvier [:bbouvier] (inactive)]

Pushing: the templates will likely get removed in bug 1181612, and try returned green:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=3988069384d5

Comment 6

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/f444a7475f87

Comment 7

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/f444a7475f87