Changes to thrinfo_t.

[devinamatthews]

• Move pba and sba pool pointers into the thrinfo_t from the rntm_t. This means we can treat the rntm_t as const (except where the ways of threading have to be modified after entry).
• Move the mem_t member from cntl_t to the thrinfo_t. This means we can treat the control tree as const during execution.
• Construct the entire thread control tree in the thread decorator. This means we can avoid the extra complexity of growing the tree as we go, and that the rntm_t is no longer needed below the level of the thread decorator.
• Slightly change the semantics of the thrinfo_t members to better match TCI to ease a future port. The only real practical ramifications of this are that 1) there is now an "extra" node at the beginning of the control tree which represents the initial thread communicator state, and 2) there is some complication with the TRSM pre-node: the splitting of threads in the IC loop doesn't happen for the pre-node (TRSM part), but the split in the control and thread info trees happens below this level. To fix this we construct the first node of the pre-node sub-tree from the KC loop thread communicator and shift any IC parallelism to the JR loop.
• Constructing the thread info tree for GEMMSUP is still rather unsatisfactory given that the threading strategy can change (requiring a re-build of the thread info tree) after the thread decorator due to transposition and/or selection of panel-block vs. block-panel algorithms. It would be nice to make these decisions earlier so that we can construct the tree only once.

[devinamatthews]

@fgvanzee I think the Windows build is failing because some of the symbol names have changed. Is there an easy way to regenerate the symbols file?

[fgvanzee]

@fgvanzee I think the Windows build is failing because some of the symbol names have changed. Is there an easy way to regenerate the symbols file?

Very maybe! I'll see what I can come up with.

[fgvanzee]

LOL. Guess what I found?

Might need some updates, but it also might work as-is.

blis/build/regen-symbols.sh

Lines 35 to 53 in 054a774

	#
	# This script regenerates a list of symbols for use when building
	# Windows-compatible DLLs. We assume that this script will be run after
	# running configure as:
	#
	# ./configure --enable-cblas haswell
	#
	# and compiling BLIS normally. (Notice that we also prune out all
	# haswell/zen-related context initialization and reference kernels.)
	#
	libblis='lib/haswell/libblis.so'
	symfile='build/libblis-symbols.def'
	echo "EXPORTS" > def.exports
	#nm -g ${libblis} | grep -o " D BLIS_.*" | cut -f2- "-dD" > def.blis_const
	nm -g ${libblis} | grep -o " T bli_.*" | cut -f2- "-dT" > def.blis
	nm -g ${libblis} | grep -o " T bla_.*" | cut -f2- "-dT" > def.blis_bla
	nm -g ${libblis} | grep -o " T cblas_.*" | cut -f2- "-dT" > def.blis_cblas

[devinamatthews]

Yes, worked like a charm. Should be fixed now.

[devinamatthews]

Oh boy, the sandbox is broken. I guess I'll fix it.

[devinamatthews]

@fgvanzee All fixed now.

[fgvanzee]

@devinamatthews I was able to get non-deterministic trsm failures just by:

1. ./configure -t openmp auto; make
2. Increasing the problem size in the input.general.fast from 100 to 300.
3. Setting export GOMP_CPU_AFFINITY="0-3" and export BLIS_NUM_THREADS=4 on my four-core KabyLake.
4. Running make check.

At least that probably answers your question of when the trsm issues began? 😕

FWIW, I observed both native (dtrsm) and complex 1m failures.

[devinamatthews]

Yes I figured it was a submarine bug. Will fix.