…ts for all relevant insn_ids simultaneously; then afterward process pairs individually; (also eliminate more unnecessary lex dims)

… that are not in {0,1} with {0,1} (we're only describing relative order, so higher int values are unnecessary and confusing)

…es in schedule outline creation since these are replaced with {0, 1} in the map simplification step. Further reduce number of lex dims in pairwise maps with the following strategy: once a lex tuple dimension is found where both tuples have non-matching integer values, remove any faster-updating lex dimensions where both tuples have integer values, even if the integers don't match.

…id_before, insn_id_after) tuples to (schedule_before, schedule_after) tuples

…ent_pairs(); don't hardcode expected lex order maps, instead create them to match expected dim size

…nsion is found where both tuples have non-matching integer values, remove all faster-updating lex dimensions.

…ts, keep all pairs in lists (of length 2) and operate on the lists with loops

…rder-and-lex-order-map

…lified lex maps

…est; probably the wrong way to do this... (but it's not time to add this to tutorial yet)

…rder-and-lex-order-map

…ements map to the exact same point(s) in the lex ordering, which is okay, but to represent this, our lex tuple cannot be empty, so map to (0))

…rder-and-lex-order-map

…e_symbolic_map_from_tuples(), all dims will always be present by construction; rename insert_missing_dims_and_reorder_by_name()->reorder_dims_by_name()

…rder-and-lex-order-map

…lacate flake8

…ults

…p across lines: add line breaks to print statement

…rder-and-lex-order-map

…g of module prefix

…ng of function

… partial list of linearization items)

…d don't warn if any such inames are found

… in generate_pairwise_schedules())

…() outside of generate_pairwise_schedules()

…ministic and remove machinery for handling multiple potential orderings

…n in reorder_dims_by_name()

…s match)

…tion

…nest-constraint-semantics-development'

LexSchedule and Map Creation

See merge request inducer/loopy!384

…t' of https://gitlab.tiker.net/inducer/loopy into new-dependency-and-nest-constraint-semantics-development

…t' into statement-instance-order-and-lex-order-map

…ion/naming/comment improvements for clarity

…cs-development

…cs-development

…t' into statement-instance-order-and-lex-order-map

…t' into statement-instance-order-and-lex-order-map

…t' of gitlab.tiker.net:inducer/loopy into new-dependency-and-nest-constraint-semantics-development

…t' into statement-instance-order-and-lex-order-map

…cs-development

…t' into statement-instance-order-and-lex-order-map

…uplicating logic when we start dealing with parallel loops and map dims for LID/GID tags

…ld merge request; don't extract initial iteration in add_dims_to_isl_set() (why did I do this before??)

… require that corresponding parallel dims be equal; changed function signatures for get_lex_order_set() and create_lex_order_map()

… map creation with parallel hw tags; more tests for schedule creation with parallel hw tags; improve variable naming a bit

…ready tested separately, and may not be returned with schedule maps later)

…now; dealing with issue found)

…ules; add test for SIO creation with parallel inames; update other tests accordinglyly

…ther than returning schedules and lex maps separately and combining them outside function to get SIOs) to avoid passing extra info around.

… still WIP and needs cleanup/tests

…arated from (global) gblex stuff

…r lblex maps during instruction pass instead of before

…t_from_names(), add_ne_isl_constraint_from_names()

…ap; instead add them after creating the traditional ordering using the existing functions

… place before aligning dims. duh.

… lid/gid dims

…ap names don't match instead of just failing on assert