Files
mercury/tests/debugger/declarative/trust.exp
Zoltan Somogyi 9bdc5db590 Try to work around the Snow Leopard linker's performance problem with
Estimated hours taken: 20
Branches: main

Try to work around the Snow Leopard linker's performance problem with
debug grade object files by greatly reducing the number of symbols needed
to represent the debugger's data structures.

Specifically, this diff groups all label layouts in a module, each of which
previously had its own named global variable, into only a few (one to four)
global variables, each of which is an array. References to the old global
variables are replaced by references to slots in these arrays.

This same treatment could also be applied to other layout structures. However,
most layouts are label layouts, so doing just label layouts gets most of the
available benefit.

When the library and compiler are compiled in grade asm_fast.gc.debug,
this diff leads to about a 1.5% increase in the size of their generated C
source files (from 338 to 343 Mb), but a more significant reduction (about 17%)
in the size of the corresponding object files (from 155 to 128 Mb). This leads
to an overall reduction in disk requirements from 493 to 471 Mb (about 4.5%).
Since we generate the same code and data as before, with the data just being
arranged differently, the decrease in object file sizes is coming from the
reduction in relocation information, the information processed by the linker.
This should speed up the linker.

compiler/layout.m:
	Make the change described above. We now define up to four arrays:
	one each for label layouts with and without information about
	variables, one for the layout structures of user events,
	and one for the variable number lists of user events.

compiler/layout_out.m:
	Generate the new arrays that the module being compiled needs.

	Use purpose-specific types instead of booleans.

compiler/trace_gen.m:
	Use a new field in foreign_proc_code instructions to record the
	identity of any labels whose layout structures we want to refer to,
	even though layout structures have not been generated yet. The labels
	will be looked up in a map (generated together with the layout
	structures) by llds_out.m.

compiler/llds.m:
	Add this extra field to foreign_proc_code instructions.

	Add the map (which is actually in two parts) to the c_file type,
	which is the data structure representing the entire LLDS.

	Also add to the c_file type some other data structures that previously
	we used to hand around alongside it. Some of these data structures
	used to conmingle layout structures that we now separate.

compiler/stack_layout.m:
	Generate array slots instead of separate structures for label layouts.
	Return the different arrays separately.

compiler/llds_out.m:
	Order the output of layout structures to require fewer forward
	declarations. The forward declarations of the few arrays holding the
	label layout structures replace a lot of the declarations previously
	needed.

	Include the information needed by layout_out.m in the llds_out_info,
	and conform to the changes above.

	As a side-effect of all these changes, we now generate proc layout
	structures in the same order as the procedures' appearence in the HLDS,
	which is the same as their order in the source code, modulo any
	procedures added by the compiler itself (for lambdas, unification
	predicates, etc).

compiler/code_info.m:
compiler/dupelim.m:
compiler/dup_proc.m:
compiler/exprn_aux.m:
compiler/frameopt.m:
compiler/global_data.m:
compiler/ite_gen.m:
compiler/jumpopt.m:
compiler/livemap.m:
compiler/llds_to_x86_64.m:
compiler/mercury_compile_llds_back_end.m:
compiler/middle_rec.m:
compiler/opt_debug.m:
compiler/opt_util.m:
compiler/pragma_c_gen.m:
compiler/proc_gen.m:
compiler/reassign.m:
compiler/use_local_vars.m:
	Conform to the changes above.

runtime/mercury_goto.h:
	Add the macros used by the new code in layout_out.m and llds_out.m.
	We need new macros because the old ones assumed that the
	C preprocessor can construct the address of a label's layout structure
	from the name of the label, which is obviously no longer possible.

	Make even existing families of macros handle in bulk up to 10 labels,
	up from the previous 8.

runtime/mercury_stack_layout.h:
	Add macros for use by the new code in layout.m.

tests/debugger/*.{inp,exp}:
tests/debugger/declarative/*.{inp,exp}:
	Update these test cases to account for the new (and better) order
	of proc layout structures. Where inputs changed, this was to ensure
	that we still select the same procedures from lists of procedures,
	e.g. to put a breakpoint on.
2009-10-21 06:36:37 +00:00

94 lines
2.4 KiB
Plaintext

E1: C1 CALL pred trust.main/2-0 (cc_multi) trust.m:13
mdb> mdb> mdb> Contexts will not be printed.
mdb> echo on
Command echo enabled.
mdb> trust trust_1.
Ambiguous predicate or function specification. The matches are:
0: pred trust_1.w_cmp/3
1: pred trust_1.lambda_trust_1_m_15/3
Which predicate or function do you want to trust (0-1 or *)? *
Trusting pred trust_1.w_cmp/3
Trusting pred trust_1.lambda_trust_1_m_15/3
mdb> trusted
Trusted Objects:
1: predicate trust_1.w_cmp/3
2: predicate trust_1.lambda_trust_1_m_15/3
mdb> untrust 1
mdb> trusted
Trusted Objects:
2: predicate trust_1.lambda_trust_1_m_15/3
mdb> untrust 2
mdb> trusted
There are no trusted modules, predicates or functions.
mdb> trust trust_2
Trusting module trust_2
mdb> trust trust.
Ambiguous predicate or function specification. The matches are:
0: pred trust.main/2
1: pred trust.dostuff/2
Which predicate or function do you want to trust (0-1 or *)? 0
Trusting pred trust.main/2
mdb> trusted
Trusted Objects:
3: module trust_2
4: predicate trust.main/2
mdb> trust trust_2
Trusting module trust_2
mdb> trusted
Trusted Objects:
3: module trust_2
4: predicate trust.main/2
mdb> untrust 3
mdb> trust trust_1
Trusting module trust_1
mdb> trust no_such_module
mdb: there is no such module, predicate or function.
mdb> trust trust_2.
Trusting pred trust_2.concat/3
mdb> trust std lib
Trusting the Mercury standard library
mdb> trust standard library
Trusting the Mercury standard library
mdb> trusted
Trusted Objects:
4: predicate trust.main/2
5: module trust_1
6: predicate trust_2.concat/3
7: the Mercury standard library
mdb> untrust 4
mdb> trusted
Trusted Objects:
5: module trust_1
6: predicate trust_2.concat/3
7: the Mercury standard library
mdb> untrust 4
mdb: no such trusted object
mdb> untrust 99
mdb: no such trusted object
mdb> untrust 5
mdb> untrust 6
mdb> step
E2: C2 CALL pred trust.dostuff/2-0 (cc_multi)
mdb> finish
E3: C2 EXIT pred trust.dostuff/2-0 (cc_multi)
mdb> dd -d 3 -n 7
dostuff(w("aaabbb"), '=')
Valid? n
w_cmp('=', w("aaB"), w("aAB"))
Valid? trust
concat(w("aaa"), w("bbb"), w("aaabbb"))
Valid? trust module
lambda_trust_1_m_15(w("aaB"), w("aAB"), '=')
Valid? trust module
Found incorrect contour:
w_cmp('=', w("aaB"), w("aAB"))
concat(w("aaa"), w("bbb"), w("aaabbb"))
dostuff(w("aaabbb"), '=')
Is this a bug? y
E3: C2 EXIT pred trust.dostuff/2-0 (cc_multi)
mdb> continue
aaabbb
'='