PIPS
|
Functions | |
void | set_conflict_testing_properties () |
conflicts.c More... | |
bool | effects_must_conflict_p (effect eff1, effect eff2) |
Intersection tests. More... | |
bool | effects_might_conflict_even_read_only_p (effect eff1, effect eff2) |
Check if two effect might conflict, even if they are read only @description Two effects may conflict if their abstract two location sets has a non-empty intersection. More... | |
bool | effects_may_conflict_p (effect eff1, effect eff2) |
Check if two effect may conflict @description Two effects may conflict if their abstract two location sets has a non-empty intersection and if at least one of them is a write. More... | |
static bool | old_effects_conflict_p (effect eff1, effect eff2) |
OBSOLETE, was never used !! More... | |
bool | effects_conflict_p (effect eff1, effect eff2) |
Synonym for effects_may_conflict_p(). More... | |
bool | array_references_may_conflict_p (list sl1, list sl2) |
Check if there may be a conflict between two array references. More... | |
bool | variable_references_may_conflict_p (entity v, list sl1, list sl2) |
FIXME ? More... | |
bool | references_may_conflict_p (reference r1, reference r2) |
Check if two references may conflict. More... | |
bool | references_must_conflict_p (reference r1, reference r2) |
Check if two references may conflict. More... | |
static bool | cells_maymust_conflict_p (cell c1, cell c2, bool must_p) |
Check if two cell may or must conflict. More... | |
bool | cells_may_conflict_p (cell c1, cell c2) |
Check if two cell may conflict. More... | |
bool | points_to_cell_lists_may_conflict_p (list l1, list l2) |
Same as above, but for lists. More... | |
bool | cells_must_conflict_p (cell c1, cell c2) |
Check if two cell must conflict. More... | |
bool | points_to_cell_lists_must_conflict_p (list l1, list l2) |
Same as above, but for lists. More... | |
bool | entities_maymust_conflict_p (entity e1, entity e2, bool must_p) |
Check if two entities may or must conflict. More... | |
bool | entities_may_conflict_p (entity e1, entity e2) |
Check if two entities may conflict. More... | |
bool | entities_must_conflict_p (entity e1, entity e2) |
Check if two entities must conflict. More... | |
static bool | first_reference_certainly_includes_second_reference_p (reference r1, reference r2) |
Inclusion tests. More... | |
static bool | first_cell_certainly_includes_second_cell_p (cell c1, cell c2) |
tests whether first cell certainly includes second one More... | |
bool | first_effect_certainly_includes_second_effect_p (effect eff1, effect eff2) |
tests whether first effect certainly includes second one. More... | |
bool | first_exact_scalar_effect_certainly_includes_second_effect_p (effect eff1, effect eff2) |
bool | effect_may_read_or_write_memory_paths_from_entity_p (effect ef, entity e) |
misc functions More... | |
bool | effects_may_read_or_write_memory_paths_from_entity_p (list l_eff, entity e) |
tests whether the input effects list may contain effects with a memory path from the input entity e; this is currently a mere syntactic test. More... | |
bool | generic_effects_maymust_read_or_write_scalar_entity_p (list fx, entity e, bool must_p, bool concrete_p) |
bool | effects_maymust_read_or_write_scalar_entity_p (list fx, entity e, bool must_p) |
bool | concrete_effects_maymust_read_or_write_scalar_entity_p (list fx, entity e, bool must_p) |
bool | effects_may_read_or_write_scalar_entity_p (list fx, entity e) |
check whether scalar entity e may be read or written by effects fx or cannot be accessed at all More... | |
bool | concrete_effects_may_read_or_write_scalar_entity_p (list fx, entity e) |
bool | effects_must_read_or_write_scalar_entity_p (list fx, entity e) |
check whether scalar entity e must be read or written by any effect of fx or if it simply might be accessed. More... | |
static list | generic_effects_entities_which_may_conflict_with_scalar_entity (list fx, entity e, bool concrete_p) |
Returns the list of entities used in effect list fx and potentially conflicting with e. More... | |
list | effects_entities_which_may_conflict_with_scalar_entity (list fx, entity e) |
list | concrete_effects_entities_which_may_conflict_with_scalar_entity (list fx, entity e) |
Variables | |
static bool | constant_path_effects_p = true |
Properties settings for conflict testing functions. More... | |
static bool | trust_constant_path_effects_p = false |
static bool | user_effects_on_std_files_p = false |
static bool | aliasing_across_types_p = true |
static bool | aliasing_across_formal_parameters_p = false |
Check if there may be a conflict between two array references.
@description May the two references to array a using subscript list sl1 and sl2 access the same memory locations?
Subscript list sl1 and sl2 can be evaluated in two different stores.
It is assumed that dim(a)=length(sl1)=length(sl2);
If the nth subscript expression can be statically evaluated in both sl1 and sl2 and if the subscript values are different, there is not conflict. For instance a[i][0] does not conflict with a[j][1]. SG: this is only true if you assume no out-of-bound indices e.g int a[2][2]; a[1][0] conflict with a[0][2] ..
This is about the old references_conflict_p()
sl1 | l1 |
sl2 | l2 |
Definition at line 276 of file conflicts.c.
References CAR, ENDP, EXPRESSION, expression_integer_value(), intptr_t, list_undefined, POP, and unbounded_expression_p().
Referenced by variable_references_may_conflict_p().
Check if two cell may conflict.
c1 | 1 |
c2 | 2 |
Definition at line 696 of file conflicts.c.
References cells_maymust_conflict_p().
Referenced by effects_might_conflict_even_read_only_p(), gen_may_set(), points_to_cell_lists_may_conflict_p(), and statement_with_side_effect_p().
Check if two cell may or must conflict.
must_p | if set to true, we enforce a must conflict |
Definition at line 667 of file conflicts.c.
References cell_preference, cell_preference_p, cell_reference, cell_reference_p, pips_internal_error, preference_reference, reference_undefined, reference_undefined_p, references_may_conflict_p(), and references_must_conflict_p().
Referenced by cells_may_conflict_p(), and cells_must_conflict_p().
Check if two cell must conflict.
c1 | 1 |
c2 | 2 |
Definition at line 722 of file conflicts.c.
References cells_maymust_conflict_p().
Referenced by effects_must_conflict_p(), and points_to_cell_lists_must_conflict_p().
fx | x |
Definition at line 1278 of file conflicts.c.
References generic_effects_entities_which_may_conflict_with_scalar_entity().
Referenced by precondition_intra_to_inter().
fx | x |
Definition at line 1220 of file conflicts.c.
References concrete_effects_maymust_read_or_write_scalar_entity_p(), and read_or_write().
Referenced by generic_transformer_intra_to_inter().
fx | x |
must_p | ust_p |
Definition at line 1202 of file conflicts.c.
References generic_effects_maymust_read_or_write_scalar_entity_p().
Referenced by concrete_effects_may_read_or_write_scalar_entity_p().
misc functions
tests whether the input effect has a memory path from the input entity e; this is currently a mere syntactic test.
other strategies could be implemented, such as building all the memory locations reachable from "e" using generic_effect_generate_all_accessible_paths_effects_with_level, and then testing whether in the resulting effects there is an effect which may conflict with en effect from the input list. However, this would be very costly.
ef | f |
Definition at line 1103 of file conflicts.c.
References effect_any_reference, entity_variable_p, read_or_write(), reference_variable, same_entity_p(), and store_effect_p().
Referenced by effects_may_read_or_write_memory_paths_from_entity_p(), and mask_effects().
Synonym for effects_may_conflict_p().
@description Name preserved to limit rewriting of source code using the old version. Also checks results of new implementation wrt the old implementation FIXME : to be removed: was never used until now !
In general, there is no reason to have the same results... This is only a first debugging step.
eff1 | ff1 |
eff2 | ff2 |
Definition at line 246 of file conflicts.c.
References effects_may_conflict_p(), old_effects_conflict_p(), and pips_internal_error.
fx | x |
Definition at line 1273 of file conflicts.c.
References generic_effects_entities_which_may_conflict_with_scalar_entity().
Check if two effect may conflict @description Two effects may conflict if their abstract two location sets has a non-empty intersection and if at least one of them is a write.
This function is conservative: it is always correct to declare a conflict.
eff1 | ff1 |
eff2 | ff2 |
Definition at line 162 of file conflicts.c.
References action_read_p, effect_action, and effects_might_conflict_even_read_only_p().
Referenced by conflict_is_a_real_conflict_p(), effects_conflict_p(), and two_addresses_code_generator().
tests whether the input effects list may contain effects with a memory path from the input entity e; this is currently a mere syntactic test.
other strategies could be implemented, such as building all the memory locations reachable from "e" using generic_effect_generate_all_accessible_paths_effects_with_level, and then testing whether in the resulting effects there is an effect which may conflict with en effect from the input list. However, this would be very costly.
l_eff | _eff |
Definition at line 1130 of file conflicts.c.
References EFFECT, effect_may_read_or_write_memory_paths_from_entity_p(), entity_variable_p, FOREACH, and read_or_write().
Referenced by compute_one_summary_reduction(), and compute_summary_reductions().
check whether scalar entity e may be read or written by effects fx or cannot be accessed at all
In semantics, e can be a functional entity such as constant string or constant float.
fx | x |
Definition at line 1214 of file conflicts.c.
References effects_maymust_read_or_write_scalar_entity_p(), and read_or_write().
Referenced by generic_transformer_intra_to_inter().
fx | x |
must_p | ust_p |
Definition at line 1197 of file conflicts.c.
References generic_effects_maymust_read_or_write_scalar_entity_p().
Referenced by effects_may_read_or_write_scalar_entity_p(), and effects_must_read_or_write_scalar_entity_p().
Check if two effect might conflict, even if they are read only @description Two effects may conflict if their abstract two location sets has a non-empty intersection.
This function is conservative: it is always correct to declare a conflict.
For environment and type declarations, the references are empty and the conflict is only based on the referenced entity
eff1 | ff1 |
eff2 | ff2 |
Definition at line 123 of file conflicts.c.
References action_kind_store_p, action_kind_tag, action_to_action_kind(), cells_may_conflict_p(), effect_action, effect_cell, and effect_variable.
Referenced by add_conflicts(), and effects_may_conflict_p().
Intersection tests.
Check if two effects always conflict. @descriptionTwo effects will always conflict if their two abstract locations has a non-empty intersection and if at least one of them is a write. The approximation must also be "MUST", if one of them is a "MAY" there is no conflict
This function is conservative: it is always correct not to declare a conflict.
We enforce must approximation for the two effects
We enforce that at least one effect is a write
Check that the cells conflicts
eff1 | ff1 |
eff2 | ff2 |
Definition at line 93 of file conflicts.c.
References action_write_p, approximation_exact_p, cells_must_conflict_p(), effect_action, effect_approximation, and effect_cell.
check whether scalar entity e must be read or written by any effect of fx or if it simply might be accessed.
In semantics, e can be a functional entity such as constant string or constant float.
fx | x |
Definition at line 1235 of file conflicts.c.
References effects_maymust_read_or_write_scalar_entity_p(), and read_or_write().
Check if two entities may conflict.
e1 | 1 |
e2 | 2 |
Definition at line 984 of file conflicts.c.
References entities_maymust_conflict_p().
Referenced by add_conflicts(), add_implicit_interprocedural_write_effects(), add_or_kill_equivalenced_variables(), apply_abstract_effect_to_transformer(), check_for_effected_statement(), direct_written_reference(), effects_read_variable_p(), effects_write_variable_p(), entity_may_conflict_with_a_formal_parameter_p(), find_covering_reference_path(), find_reduction_of_var(), functionnal_on_effects(), generic_effects_entities_which_may_conflict_with_scalar_entity(), generic_effects_maymust_read_or_write_scalar_entity_p(), get_effect_read_of_statement_on_variable(), get_effect_write_of_statement_on_variable(), initialize_and_verify_common_variable(), interference_on(), list_of_same_or_equivalence_arguments(), no_other_effects_on_references(), no_write_effects_on_var(), old_effects_conflict_p(), points_to_cells_intersect_p(), reference_rwt(), references_may_conflict_p(), remove_unread_variable(), there_is_a_conflict(), transformer_general_consistency_p(), update_compatible_reduction(), update_compatible_reduction_with(), update_reduction_under_effect(), value_alias(), and verify_formal_and_common_variables().
Check if two entities may or must conflict.
FI->MA: we certainly said a lot more during the February 2010 meeting, when abstract locations were added. And now we have store and type declaration dependencies...
must_p | define if we enforce must conflict or only may one |
Be careful because entity_variable_p(e) does not guarantee that e is a variable defined by the programmer. Maybe another function is needed to make sure that the conversion to an abstract location generates a useful result... variable_entity_p() is not necessarily good either because it uses the entity storage to make a decision. Formal parameters and return values are not taken into account.
There no abstract locations for formal parameters and return values, which may not be a good idea if C let you pick up the address of a formal parameter. They have to be handled in a specific way.
Beware: this function should only be used for scalar entities. however, I do not add an assert for this time, because I don't yet know what damages it may cause...
Constant strings may be tested because they are used to represent the underlying buffers. The effect should always be a read effect.
FI: Either we need an new abstract location for the formal parameters or we need to deal explictly with this case here and declare conflict with anywhere.
FIXME : variable_entity_must_conflict_p does not exist yet
A must conflict is useful to guarantee a kill, but this shows that it is not related to the definition of the may case: two variables may share exactly the same set of memory locations but a reference to one of them does not necessarily imply that all locations are read or written. More comments (thinking) are needed to distinguish between entity and reference conflicts.
We assume that e1 and e2 are program variables. Because we do not have enough comments, we do not know if this only hold for variables and arrays of one element. It is easy to argue that an array cannot must conflict with itself. The test below does not solve the case of struct, and maybe union.
FI: should always be the case here but a struct variable is a scalar, as well as the location entities representing its field. They are aliased as equivalenced Fortran variables. The case of struct and struct field can be solved at a higher level by converting effects to their location entities when it makes sense instead of relying on the effect base variable.
FI: we end up here if references linked to environment or type declarations are tested for conflicts. Should we perform such tests, basically e1==e2, or assume that they should have been handled at a higher level?
There are no conflicts between entities of different kinds
Since this implies e1!=e2, this case could be merged with the next one, but the spec would be less clear
Environment and type declaration conflicts imply that the very same entity is involved.
e1 | 1 |
e2 | 2 |
must_p | ust_p |
Definition at line 771 of file conflicts.c.
References abstract_locations_may_conflict_p(), abstract_locations_must_conflict_p(), c_module_p(), constant_string_entity_p(), effects_package_entity_p(), entity_abstract_location_p(), entity_all_locations_p(), entity_anywhere_locations_p(), entity_basic_concrete_type(), entity_formal_p(), entity_function_p(), entity_initial, entity_null_locations_p(), entity_register_p(), entity_scalar_p(), entity_user_name(), false, get_current_module_entity(), location_entity_p(), overloaded_type_p(), pips_debug, pips_internal_error, reference_variable, same_entity_p(), type_equal_p(), type_variable_p, value_reference, variable_entities_may_conflict_p(), variable_entity_p(), variable_return_p(), and variable_to_abstract_location().
Referenced by entities_may_conflict_p(), and entities_must_conflict_p().
Check if two entities must conflict.
e1 | 1 |
e2 | 2 |
Definition at line 992 of file conflicts.c.
References entities_maymust_conflict_p().
Referenced by generic_effects_maymust_read_or_write_scalar_entity_p(), references_must_conflict_p(), and remove_unread_variable().
tests whether first cell certainly includes second one
safe result
Definition at line 1026 of file conflicts.c.
References cell_to_reference(), and first_reference_certainly_includes_second_reference_p().
Referenced by first_effect_certainly_includes_second_effect_p(), and first_exact_scalar_effect_certainly_includes_second_effect_p().
tests whether first effect certainly includes second one.
The effects are not necessarily functions of the same store.
This means that a[i]-exact does not necessarily contains a[i]-exact because i may not have the same value in the store to which the effects refer. This is the case for instance in the following code:
i = 1; a[i] = ...; // S1 i = 2; a[i] = ...; // S2
The assignment in S2 does not kill the assignment in S2;
This function could be improved for convex effects by eliminating from Psystems program variables which are not common inclosing loop variants. this would require much more information than what we currently have.
So in all cases, the function safely returns false for effects described with access paths which are not single entities.
safe result
eff1 | ff1 |
eff2 | ff2 |
Definition at line 1060 of file conflicts.c.
References effect_cell, effect_exact_p, effect_scalar_p(), and first_cell_certainly_includes_second_cell_p().
safe result
eff1 | ff1 |
eff2 | ff2 |
Definition at line 1074 of file conflicts.c.
References effect_cell, effect_exact_p, effect_scalar_p(), first_cell_certainly_includes_second_cell_p(), and pips_assert.
Referenced by kill_effects().
|
static |
Inclusion tests.
I'm not sure that testing must conflicts makes much sense with sets of memory locations. We cannot well define a symmetrical semantics. However, testing the inclusion makes sense! BC. tests whether first reference certainly includes second one
safe result
Definition at line 1010 of file conflicts.c.
References reference_scalar_p(), reference_variable, and same_entity_p().
Referenced by first_cell_certainly_includes_second_cell_p().
|
static |
Returns the list of entities used in effect list fx and potentially conflicting with e.
Of course, abstract location entities do conflict with many entities, possibly of different types.
if concrete_p==true, ignore abstract location entities.
Definition at line 1251 of file conflicts.c.
References CONS, EFFECT, effect_any_reference, entities_may_conflict_p(), ENTITY, entity_abstract_location_p(), FOREACH, gen_nconc(), NIL, and reference_variable.
Referenced by concrete_effects_entities_which_may_conflict_with_scalar_entity(), and effects_entities_which_may_conflict_with_scalar_entity().
bool generic_effects_maymust_read_or_write_scalar_entity_p | ( | list | fx, |
entity | e, | ||
bool | must_p, | ||
bool | concrete_p | ||
) |
Used to be a simple pointer equality test, but now we have to cope with abstract locations.
fx | x |
must_p | ust_p |
concrete_p | oncrete_p |
Definition at line 1144 of file conflicts.c.
References constant_memory_access_path_to_location_entity(), EFFECT, effect_any_reference, ENDP, entities_may_conflict_p(), entities_must_conflict_p(), entity_abstract_location_p(), entity_initial, entity_scalar_p(), entity_undefined, entity_undefined_p, entity_variable_p, FOREACH, location_entity_p(), read_or_write(), reference_indices, reference_variable, references_may_conflict_p(), references_must_conflict_p(), store_effect_p(), and value_reference.
Referenced by concrete_effects_maymust_read_or_write_scalar_entity_p(), and effects_maymust_read_or_write_scalar_entity_p().
OBSOLETE, was never used !!
Do we point to the same area?
We do not bother with the offset and the array types
Definition at line 180 of file conflicts.c.
References action_write_p, anywhere_effect_p(), CAR, effect_action, effect_any_reference, ENDP, entities_may_conflict_p(), EXPRESSION, expression_integer_value(), intptr_t, list_undefined, POP, reference_indices, reference_variable, and unbounded_expression_p().
Referenced by effects_conflict_p().
Same as above, but for lists.
Lists conflict if there exist at least one element in l1 and one element in l2 that conflict.
l1 | 1 |
l2 | 2 |
Definition at line 703 of file conflicts.c.
References CELL, cells_may_conflict_p(), and FOREACH.
Referenced by aliased_translation_p().
Same as above, but for lists.
Lists conflict if there exist at least one element in l1 and one element in l2 that must conflict.
l1 | 1 |
l2 | 2 |
Definition at line 729 of file conflicts.c.
References CELL, cells_must_conflict_p(), and FOREACH.
Referenced by aliased_translation_p().
Check if two references may conflict.
@description Can the two references r1 and r2 access the same memory location when evaluated in two different stores?
We have to deal with static aliasing for Fortran and with dynamic aliasing for C and Fortran95.
We have to deal with abstract locations used to represent sets of memory locations.
A PIPS reference is a memory access path rather than a reference as understood in programming languages:
Three bool properties are involved:
calling entities_may_conflict_p is only valid for scalar entities
here, we have either two concrete locations, one of which at least has indices, or one abstract location and one concrete location with indices. BC
I'm not completely sure of that. Are numbered heap locations considered as abstract locations? And they may have indices. Heap locations testing is a mess. BC.
FI: Can we have some dynamic aliasing?
Do we have aliasing between types?
Do we have aliasing within a data structure? This should have been checked above with variable_references_may_conflict_p(v1,ind1,ind2)
A patch for effects_package references, which cannot conflict with user variables
well, strictly speaking, couldn't they conflict with an anywhere:anywhere effect? but then there should be other conflicts...
string operations are costly - perform them only once
well type_equal_p does not perform a good job :-( BC
should ALIASING_ACROSS_DATA_STRUCTURES be also tested here?
Do we have some dereferencing in ind1 or ind2? Do we assume that p[0] conflicts with any reference? We might as well use reference_to_abstract_location()...
Could be improved with ALIASING_ACROSS_DATA_STRUCTURES?
We need to evaluate dereferencing in r2 only when a dereferencing have not been find in r1
In other words, we assume no conflict as soon as no pointer is dereferenced... even when aliasing across types is not ignored !
If aliasing across types is ignored, we know here that the two memory locations referenced are of the same type. If the pointer in one reference (let's assume only one pointer to start with) is not of type pointer to the common type, then there is no conflict.
Else, we have to assume a conflict no matter what, because simple cases should have been simplified via the points-to analysis.
r1 | 1 |
r2 | 2 |
Definition at line 426 of file conflicts.c.
References aliasing_across_formal_parameters_p, aliasing_across_types_p, c_module_p(), cell_reference_to_type(), constant_path_effects_p, effect_reference_dereferencing_p(), effect_reference_to_string(), effects_package_entity_p(), ENDP, entities_may_conflict_p(), entity_abstract_location_p(), entity_all_locations_p(), entity_flow_or_context_sentitive_heap_location_p(), entity_formal_p(), entity_null_locations_p(), free_type(), get_bool_property(), get_current_module_entity(), pips_assert, pips_debug, reference_indices, reference_variable, same_entity_p(), std_file_entity_p(), trust_constant_path_effects_p, type_equal_p(), user_effects_on_std_files_p, variable_entities_may_conflict_p(), and variable_references_may_conflict_p().
Referenced by apply_array_effect_to_transformer(), cells_maymust_conflict_p(), do_atomize_call(), do_symbolic_tiling(), generic_effects_maymust_read_or_write_scalar_entity_p(), generic_reference_to_transformer(), and invalidate_expressions_in_statement().
Check if two references may conflict.
@description See references_may_conflict_p
pips_user_warning("Not completely implemented yet. " "Conservative under approximation is made\n");
Check for constant subscripts
r1 | 1 |
r2 | 2 |
Definition at line 607 of file conflicts.c.
References CAR, effect_reference_to_string(), entities_must_conflict_p(), entity_field_p(), EXPRESSION, expression_equal_p(), expression_reference(), expression_reference_p(), extended_expression_constant_p(), FOREACH, gen_length(), int, pips_debug, POP, reference_indices, reference_scalar_p(), and reference_variable.
Referenced by cells_maymust_conflict_p(), and generic_effects_maymust_read_or_write_scalar_entity_p().
void set_conflict_testing_properties | ( | void | ) |
Definition at line 68 of file conflicts.c.
References aliasing_across_formal_parameters_p, aliasing_across_types_p, constant_path_effects_p, get_bool_property(), trust_constant_path_effects_p, and user_effects_on_std_files_p.
Referenced by chains(), do_symbolic_tiling(), generate_two_addresses_code(), and simdizer().
FIXME ?
@description May the two references to v using subscript list sl1 and sl2 access the same memory locations?
Subscript list sl1 and sl2 can be evaluated in two different stores.
FI: this code seems to assume that ALIASING_ACROSS_DATA_STRUCTURES is set to FALSE.
This is equivalent to a simple Fortran-like array reference
FI: this is new not really designed (!) code
Because of heap modelization functions can be used as subscript. Because of struct and union modelization, fields can be used as subscripts.
context sensitive heap modelization
assume the code is correct... Assume no floating point index... a[i] vs a[x]...
sl1 | l1 |
sl2 | l2 |
Definition at line 314 of file conflicts.c.
References array_references_may_conflict_p(), CAR, ENDP, entity_field_p(), entity_name, entity_type, EXPRESSION, expression_integer_value(), expression_reference_p(), expression_variable(), gen_length(), intptr_t, list_undefined, POP, s1, same_entity_p(), same_string_p, type_equal_p(), type_functional_p, type_struct_variable_p(), type_union_variable_p(), type_variable, unbounded_expression_p(), and variable_dimensions.
Referenced by references_may_conflict_p().
Definition at line 66 of file conflicts.c.
Referenced by references_may_conflict_p(), and set_conflict_testing_properties().
Definition at line 65 of file conflicts.c.
Referenced by references_may_conflict_p(), and set_conflict_testing_properties().
Properties settings for conflict testing functions.
These settings are done for performance reasons, especially in chains initial values are current default values
Definition at line 62 of file conflicts.c.
Referenced by references_may_conflict_p(), and set_conflict_testing_properties().
Definition at line 63 of file conflicts.c.
Referenced by references_may_conflict_p(), and set_conflict_testing_properties().
Definition at line 64 of file conflicts.c.
Referenced by references_may_conflict_p(), and set_conflict_testing_properties().