client.mk
author Iain Ireland <iireland@mozilla.com>
Tue, 19 Mar 2019 23:22:04 +0000
changeset 465227 d808eb8f5dd52d49348586d0764ecf8a419d1e9f
parent 441525 6dad1580bc3ea76a5239ef86a78e82745f197f5a
permissions -rw-r--r--
Bug 1533890: Add scripted constructor support to CacheIR r=mgaudet This patch adds support for scripted constructors, using the existing template object infrastructure. Comparison points: - BaselineCacheIRCompiler::createThis/updateReturnValue correspond to big "if (isConstructing) ..." blocks in ICCallScriptedCompiler::generateStubCode. - CallIRGenerator::getTemplateObjectForScripted corresponds to the block in tryAttachCallStub starting with the comment "// Remember the template object ..." Notes: 1. In the original CreateThis code, there was the following comment: // Reload callee script. Note that a GC triggered by CreateThis may // have destroyed the callee BaselineScript and IonScript. CreateThis // is safely repeatable though, so in this case we just leave the stub // frame and jump to the next stub. This comment was out of date; as of bug 1415853, the code pointer is always valid. The comment does not exist in the new version. 2. Bug 870478 added code to the old version of |updateReturnValue| to load |this| from the baseline frame instead of the baseline stub frame, because we would not trace the copy of |this| if a rectifier frame was created. A better fix was delivered in bug 945275 (we now trace |this| in rectifier frames). The new version of |updateReturnValue| loads |this| out of the stub frame, because it is both easier to read and more efficient. 3. Unlike BaselineInspector::getTemplateObjectFor(Native|ClassHook), the scripted version does not use the callee as a guard to make sure that we have the correct template object. This is the same as the status quo. It works because we only retrieve the template object if the IC chain has exactly one non-fallback stub. We still store the callee in the metadata, because it is needed for BaselineInspector::getSingleCallee. This whole area of the BaselineInspector API should probably be redesigned, but it seemed out of scope for this patch. Differential Revision: https://phabricator.services.mozilla.com/D22782

# -*- makefile -*-
# vim:set ts=8 sw=8 sts=8 noet:
# This Source Code Form is subject to the terms of the Mozilla Public
# License, v. 2.0. If a copy of the MPL was not distributed with this
# file, You can obtain one at http://mozilla.org/MPL/2.0/.

# Defines main targets for driving the Firefox build system.
#
# This make file should not be invoked directly. Instead, use
# `mach` (likely `mach build`) for invoking the build system.
#
# Options:
#   MOZ_OBJDIR           - Destination object directory
#   MOZ_MAKE_FLAGS       - Flags to pass to $(MAKE)
#
#######################################################################
# Defines

ifdef MACH
ifndef NO_BUILDSTATUS_MESSAGES
define BUILDSTATUS
@echo 'BUILDSTATUS $1'

endef
endif
endif


CWD := $(CURDIR)

ifeq "$(CWD)" "/"
CWD   := /.
endif

PYTHON ?= $(shell which python2.7 > /dev/null 2>&1 && echo python2.7 || echo python)

####################################
# Load mozconfig Options

include $(OBJDIR)/.mozconfig-client-mk

ifdef MOZ_PARALLEL_BUILD
  MOZ_MAKE_FLAGS := $(filter-out -j%,$(MOZ_MAKE_FLAGS))
  MOZ_MAKE_FLAGS += -j$(MOZ_PARALLEL_BUILD)
endif

# Automatically add -jN to make flags if not defined. N defaults to number of cores.
ifeq (,$(findstring -j,$(MOZ_MAKE_FLAGS)))
  cores=$(shell $(PYTHON) -c 'import multiprocessing; print(multiprocessing.cpu_count())')
  MOZ_MAKE_FLAGS += -j$(cores)
endif

ifdef MOZ_AUTOMATION
ifeq (4.0,$(firstword $(sort 4.0 $(MAKE_VERSION))))
MOZ_MAKE_FLAGS += --output-sync=line
endif
endif

MOZ_MAKE = $(MAKE) $(MOZ_MAKE_FLAGS) -C $(OBJDIR)

# 'configure' scripts generated by autoconf.
CONFIGURES := $(TOPSRCDIR)/configure
CONFIGURES += $(TOPSRCDIR)/js/src/configure

#######################################################################
# Rules

# The default rule is build
build::

ifndef MACH
$(error client.mk must be used via `mach`. Try running \
`./mach $(firstword $(MAKECMDGOALS) $(.DEFAULT_GOAL))`)
endif

# In automation, manage an sccache daemon. The starting of the server
# needs to be in a make file so sccache inherits the jobserver.
ifdef MOZBUILD_MANAGE_SCCACHE_DAEMON
build::
	# Terminate any sccache server that might still be around.
	-$(MOZBUILD_MANAGE_SCCACHE_DAEMON) --stop-server > /dev/null 2>&1
	# Start a new server, ensuring it gets the jobserver file descriptors
	# from make (but don't use the + prefix when make -n is used, so that
	# the command doesn't run in that case)
	mkdir -p $(UPLOAD_PATH)
	$(if $(findstring n,$(filter-out --%, $(MAKEFLAGS))),,+)env RUST_LOG=sccache=debug SCCACHE_ERROR_LOG=$(UPLOAD_PATH)/sccache.log $(MOZBUILD_MANAGE_SCCACHE_DAEMON) --start-server
endif

####################################
# Configure

$(CONFIGURES): %: %.in
	@echo Generating $@
	cp -f $< $@
	chmod +x $@

CONFIGURE_ENV_ARGS += \
  MAKE='$(MAKE)' \
  $(NULL)

# configure uses the program name to determine @srcdir@. Calling it without
#   $(TOPSRCDIR) will set @srcdir@ to "."; otherwise, it is set to the full
#   path of $(TOPSRCDIR).
ifeq ($(TOPSRCDIR),$(OBJDIR))
  CONFIGURE = ./configure
else
  CONFIGURE = $(TOPSRCDIR)/configure
endif

configure:: $(CONFIGURES)
	$(call BUILDSTATUS,TIERS configure)
	$(call BUILDSTATUS,TIER_START configure)
	@echo cd $(OBJDIR);
	@echo $(CONFIGURE) $(CONFIGURE_ARGS)
	@cd $(OBJDIR) && $(CONFIGURE_ENV_ARGS) $(CONFIGURE) $(CONFIGURE_ARGS) \
	  || ( echo '*** Fix above errors and then restart with\
               "./mach build"' && exit 1 )
	@touch $(OBJDIR)/Makefile
	$(call BUILDSTATUS,TIER_FINISH configure)

####################################
# Build it

build::
	+$(MOZ_MAKE)

ifdef MOZ_AUTOMATION
build::
	+$(MOZ_MAKE) automation/build
endif

# This makefile doesn't support parallel execution. It does pass
# MOZ_MAKE_FLAGS to sub-make processes, so they will correctly execute
# in parallel.
.NOTPARALLEL:

.PHONY: \
    build \
    configure